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

Johannes Schindelin [off-list ref] writes:

quoted

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

For a relatively obscure and low-impact bug that is old like this
one, I'd actually prefer to be able to say "heh, if that hurts,
either refrain from doing so, or update to the recent maintenance
track that has a fix for it", to use the fix as an incentive to move
the world forward ;-).  After all, people have lived with the bug
for a long time.