Re: What's cooking in git.git (Apr 2018, #04; Mon, 30)
- From
Junio C Hamano <gitster@pobox.com>
- Date
- May 2, 2018, 03:59 UTC
- Message-ID
- <xmqqr2muwvvq.fsf@gitster-ct.c.googlers.com>
- In-Reply-To
- <nycvar.QRO.7.76.6.1805011439580.79@tvgsbejvaqbjf.bet>
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.