On 11-10-16 03:20 AM, Junio C Hamano wrote: > As some might know, I use the traditional non-separate-remotes layout in > many of my working trees. I am old fashioned. Being hip and modern :) I use separate remote refspecs. As I read your post, I kept thinking that it makes no sense for fetch to ever update local refs and that you're a victim of your stodgy old ways. > 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. > > This is one of the many things that is so minor that it probably is not > worth risking backward compatibility issues to change, but something that > we would design differently if we were starting from scratch. Maybe in Git > 2.0. > > The question however is what should it do. I can see three possibilities: > > (1) Forcing to fetch into FETCH_HEAD does not make any sense, so instead > of silently ignoring the '+' prefix, error it out and do not fetch > anything. This is easy to explain and logically makes more sense than > the current behaviour. I think this makes the most sense. I'd even go so far as to make fetch error out if there's a colon in the refspec. Fetch has no business updating local refs. There are other commands for that, and which command you use depends on how you want your local ref updated. I think it would be a mistake to start going down a path where fetch learns different ways to update a local ref. Madness! M. -- 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