Hi Junio, On Wed, 2 May 2018, Junio C Hamano wrote:
> Johannes Schindelin <johannes.schinde...@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
