Re: What should "git fetch origin +next" should do?

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 19, 2011, 04:31 UTC
Message-ID: <7v8vohfvqs.fsf@alter.siamese.dyndns.org>
In-Reply-To: <4E9CA5E2.2020701@xiplink.com>

Marc Branchaud <marcnarc@xiplink.com> writes:

Show 5 quoted lines

> In all cases if the command-line refspec has no RHS then git should try to
> figure out which local ref to update from the config, and it should die if it
> can't figure out a local ref to create or update.  (As I said above, maybe
> allow "git fetch origin foo:" to let the user put the tip of origin's foo ref
> into FETCH_HEAD.)

I'd agree with everything you said in your message, except for the above "it should die" part.

You are assuming that the user knows what his configured refspecs would normally do and that is the whole reason why "git fetch origin next" that would update the remote tracking branch specified for the upstream's next might feel more natural than the current behaviour. I too think that is a reasonable assumption.

With the same assumption, if you said "git fetch origin frotz" when you know you are not usually tracking the remote 'frotz' branch, the command just should store what is fetched in FETCH_HEAD (and nowhere else) without dying. I do not think how it helps the user to die in that situation.

> All this gets a bit more complicated if the user has currently checked out
> the a ref that should be updated (regardless of the presence of a LHS +).

That "do not update the currently checked out branch" already exists and is correctly handled by "git fetch", I think.