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
> 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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to