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

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