From: Ramkumar Ramachandra Date: Mon, 17 Oct 2011 16:10:56 GMT Subject: Re: What should "git fetch origin +next" should do? Message-ID: In-Reply-To: <7v7h45s8rh.fsf@alter.siamese.dyndns.org> Hi Junio, Junio C Hamano writes: > 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. "" === ":", 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. >  (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. >  (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