Re: Recording the current branch on each commit?

[Felipe Contreras <felipe.contreras@gmail.com>]

David Kastrup wrote:
> 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