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