On Thu, May 16, 2013 at 10:58 AM, Junio C Hamano <gits...@pobox.com> wrote:
> I _think_ the real reason you want a "git fetch" while on "mywork"
> to go to 'origin' is because you are building your "master" off of
> somebody else's work that comes from 'origin', and you want to check
> what has changed to see what you need to rebuild both your "master"
> and "mywork" branches on top of. If 'master' were forked from a
> remote that is not 'origin', then making "git fetch" ignore '.' and
> instead go to 'origin' would not solve anything. For an updated
> behaviour to be useful in that workflow, it needs to follow the
> inter-branch relationship ("mywork is a fork of master which is a
> fork of frotz branch from a remote xyzzy") to see the first remote
> repository and fetch from there, instead of blindly fetching from
> the 'origin'.
No, the reason I want 'git fetch' to fetch 'origin' is because it has
always done so. It only stopped doing so when I configured 'upstream'
branches. I'm not even sure I want 'git fetch' to fetch from the
remote of my current branch if it has an upstream branch.
> Having said all that, I am not all that sure that it is a good idea
> to introduce such an exception for "git fetch" to ignore '.',
> regardless of where it goes instead, either the 'origin' or the
> first remote repository it finds by recursively finding its
> upstreams, to break the consistency at the UI level. It is dubious
> if the benefit of convenience to fetch from remote 'xyzzy' that is
> an eventual remote of 'mywork' without having to say so outweighs
> the cost of additional UI inconsistency, making things harder to
> explain to both new and old people.
That doesn't change the fact that 'git fetch .' does not make any
sense whatsoever. The user *will* get confused when (s)he does 'git
fetch' and nothing happens. The problem is not solved.
% git checkout -b fixes master
% git fetch
% git branch -u master
% git fetch
# scratch head
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
