Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Wed, 2 May 2018, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > So the problem you found is not a problem with *my* branch, of course, as
> > I did not fork off of ...
> 
> Correct; there is no blame on you with the choice of the base.  It
> was my mistake that I didn't check if the series could be queueable
> on the maintenance track that is one release older than the current
> 'maint'.
> 
> As I wrote elsewhere, for a low-impact and ralatively old issue like
> this, it is OK for a fix to use supporting code that only exists in
> more recent codebase and become unmergeable to anything older than
> the concurrent 'maint' track as of the time when the fix is written.
> Even though it is sometimes nicer if the fix were written to be
> mergeable to codebase near the point where the issue originates, it
> is often not worth doing so if it requires bending backwards to
> refrain from using a newer and more convenient facility.

So do you want me to clean up the backporting branches? I mean, we could
easily fix that bug for the release trains v2.13.x - v2.16.x... Of course
I do not propose to release them *now*, but if you find that another
critical bug fix necessitates maintenance releases anyway, *and* if the
branch ages well in `master`, you could simply merge them at that time.

Ciao,
Dscho