Felipe Contreras <felipe.contreras@xxxxxxxxx> writes: > Jeremy Morton wrote: >> >> Sounds like the default behaviour of "git pull" might not be ideal if >> it easily causes these problems. > > It's not idea. Virtually everyone agrees with that, even Linus > Torvalds, and we have the patches to fix it, but it's not going to > change. > > The Git project doesn't welcome change. I can think of a few other things that "the Git project" or actually pretty much everybody doesn't welcome. It becomes easier to actually change things when communicating in a less abrasive and destructive manner. At any rate, releases involve time plans and testing periods. Personally I think that the automerging behavior of "git pull" is one of the most stupid traps Git has available for beginning contributors to make a royal mess of their contributions. It's unbelievable that this has not been defused a decade ago already. But it hasn't, and such a change is no longer in a useful time frame for a 2.0 release. Unless one wants to push back the 2.0 release considerably for this alone. But then everybody will have a favorite pet peeve, some likely more justified, some less, that he wants to get into 2.0. I mean, I just sped up git-blame for serious use cases by a factor of 3 or so at least, and there will be _no_ API changes and user-visible consequences with that change. So what? If the thing has been important enough to get into 2.0, it has been important enough to push for it _timely_ so that it had a chance at considerable testing exposure. That's what has been done with the "git push" changes. They were put in timely, with quite a bit of warning about what will change and what people are supposed to be doing about it. Again: bad enough that it took as long as that to fix this insanely reckless default. The scale of the git-pull problem is small in comparison as it only messes up a single local branch instead of a whole set of upstream branches. -- David Kastrup -- 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