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. "<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. > (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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html