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

[Junio C Hamano <gitster@pobox.com>]

SZEDER Gábor <szeder.dev@gmail.com> writes:

> On Mon, Apr 30, 2018 at 5:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> * js/rebase-i-clean-msg-after-fixup-continue (2018-04-30) 4 commits
>>   - rebase --skip: clean up commit message after a failed fixup/squash
>>   - sequencer: always commit without editing when asked for
>>   - rebase -i: Handle "combination of <n> commits" with GETTEXT_POISON
>>   - rebase -i: demonstrate bugs with fixup!/squash! commit messages
>
>>   "git rebase -i" sometimes left intermediate "# This is a
>>   combination of N commits" message meant for the human consumption
>>   inside an editor in the final result in certain corner cases, which
>>   has been fixed.
>
>>   Will merge to 'next'.
>
> This topic branches off from v2.16.3.  However, its last patch uses
> the sequencer's parse_head() function, which was only added in
> v2.17.0-rc0~110^2~6 (sequencer: try to commit without forking 'git
> commit', 2017-11-24), in topic 'pw/sequencer-in-process-commit',
> leading to compilation errors.

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.

Thanks for catching my wishful thinking and carelessness before it
propagated to 'next'.  I try to check tips of individual topic
branches and also the integratoin result, but sometimes I get
trusting too much and get sloppy when dealing with too many topics
in flight.