Re: Recording the current branch on each commit?

From: David Kastrup <dak@gnu.org>
Date: Apr 28, 2014, 09:39 UTC
Message-ID: <87bnvl6bdg.fsf@fencepost.gnu.org>
In-Reply-To: <535e18cdc7bce_338911e930c72@nysa.notmuch>

Felipe Contreras <felipe.contreras@gmail.com> writes:

Show 10 quoted lines

> 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