Re: Recording the current branch on each commit?

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Apr 28, 2014, 17:22 UTC
Message-ID: <535e8e4253196_45651483310b3@nysa.notmuch>
In-Reply-To: <87bnvl6bdg.fsf@fencepost.gnu.org>

David Kastrup wrote:

Show 18 quoted lines

> Felipe Contreras <felipe.contreras@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.

That would make sense if I was the only one with the itch. But I wasn't the only one, so anybody could take the patches and send them in a less abrasive maner.

In fact I have been contacted a couple of times privately suggesting me to use a softer tone in order to get my patches applied, in every time I issue a challenge. You send the patches, and you follow up the discussion in whatever tone you see fit, if they get in, I'll accept I'm wrong and use softer tone in the future. The fact of the matter is that the tone doesn't matter, the patches don't get in because change is not welcome. Period.

> But it hasn't, and such a change is no longer in a useful time frame for
> a 2.0 release.

I sent the last version of the series in Octoboer 2013, there was more than enough time to merge them, or somebody else with more political traction to pick and finish whatever changes where needed (none).

> Unless one wants to push back the 2.0 release considerably for this alone.

Why does it need to be pushed back? Have you looked at the patches? If so, what is the risk that there will be any problem with them?

> 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.

I bet this could get into 2.0, but the big patch has to be split into smaller patches in order for them to be reviewed properly, and maybe merge a few of them at a time.

> 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.

Really? What important changes does 2.0 have? There's literally nothing of interest to most users, maybe push.default = simple, but that's it.

-- 
Felipe Contreras