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

From: Junio C Hamano <gitster@pobox.com>
Date: May 2, 2018, 10:46 UTC
Message-ID: <xmqqlgd2uygs.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <nycvar.QRO.7.76.6.1805020850400.73@tvgsbejvaqbjf.bet>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 10 quoted lines

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