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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Oct 17, 2011, 16:10 UTC
Message-ID: <CALkWK0kXyovFrJO+5AD3gOs1YuutBZouH8aESXSKA-1nX3T6rw@mail.gmail.com>
In-Reply-To: <7v7h45s8rh.fsf@alter.siamese.dyndns.org>

Hi Junio,

Junio C Hamano writes:

Show 10 quoted lines

> I just tried to update one of them with "git pull --ff-only", and after
> seeing that the fetch phase failed with non-ff on 'next', ran
>
>        $ git fetch origin +next
>
> which happily copied the tip of updated next to FETCH_HEAD and nowhere
> else. Of course, a colon-less refspec means do not store it anywhere,
> i.e. "<colon-less-refspec>" === "<colon-less refspec>:", so prefixing it
> with '+' to force would logically be a no-op.  But it nevertheless was
> somewhat surprising and irritating.

Interesting: I wouldn't have expected this behavior either.  I'll see
if I can add something useful to this.

> As some might know, I use the traditional non-separate-remotes layout in
> many of my working trees. I am old fashioned.

As an interesting aside, I recently stopped using the word 'origin' to
name a remote since I started using multiple remotes: your remote is
called 'junio', mine's called 'ram', Jonathan's is called 'jrn', and
so on.  I personally use a variation of `git fetch junio master:master
next:next +pu:pu`.  It "fails" when:
1. Some uncommitted work is left:  I'm a bit messy with multiple
worktrees (git-new-workdir).
2. I'm doing some work directly on top of `master` or some other
upstream branch, and haven't forked out yet (I only fork out and name
the branch if the volume of work justifies it).
3. Sometimes `next` is non-ff, and I'm curious about what happened.  I
inspect the changes before invariably using a `git reset --hard
junio/next` to throw away the useless commits.

Show 9 quoted lines

>  (2) Do notice '+' and understand that it is a request to force fetch into
>     some ref locally, and from the lack of colon and RHS, assume that the
>     user wants Git to infer the RHS using the configured refspec (in my
>     case, "refs/heads/next:refs/heads/next" is one of the configured
>     fetch refspec; "refs/heads/*:refs/remotes/origin/*" would be the one
>     that would match in the separate-remotes layout). In other words,
>     treat it as if the user typed "+refs/heads/next:refs/heads/next" (or
>     "+refs/heads/next:refs/remotes/origin/next" in the separate-remote
>     layout) from the command line.

Ugh, no.  Such smartness is probably desirable at the `pull` level.

Show 6 quoted lines

>  (3) Do notice '+' is applied to 'next' but otherwise ignore the fact that
>     it is a command line pathspec, which would cause us to ignore
>     configured refspecs. In other words, fetch normally as if there were
>     no refspec on the command line, but when updating refs/heads/next (or
>     refs/remotes/origin/next in the separate-remotes layout), allow non
>     fast-forward updates.

This is unnecessarily complicated and ugly imho. I think `git fetch` is trying to be over-smart here: If I don't choose to update my local refs by hand immediately after the fetch, I'll be surprised later.

> Perhaps we can/want to implement (1)?

Yeah, I think it's the right thing to do. For the implementation, should we update the condition in fetch.c:451 or try to implement it at the refspec-parsing level?

Thanks.

-- Ram