Re: [PATCH v3] sequencer: honor --empty when a fixup!/squash! empties its target

> Farid Zakaria <farid.m.zakaria@gmail.com> writes:
> 
>> When "git rebase --autosquash" melds a "fixup!" or "squash!" commit into
>> its target, the result can be a commit that no longer changes anything
>> relative to its parent, for example when the melded change reverts the
>> target.  Rather than dropping or keeping this empty commit, the rebase
>> stops with
>>
>> 	You asked to amend the most recent commit, but doing so would
>> 	make it empty. ...
>>
>> and the "--empty" option has no effect on it.  This makes backing a
>> change out of a series awkward: reverting a commit as a "fixup!" and
>> running "git rebase --autosquash --empty=drop" ought to remove both the
>> commit and its revert, but it halts instead.
>> ...
>> Changes in v3:
>>   * Switch the new tests' assertions from grep to test_grep for better
>>     diagnostics (per review).
>>   * Link to v2: https://lore.kernel.org/r/20260710-fz-autosquash-empty-v2-1-fa1e277e05f8@gmail.com
> 
> I see you are already working well with Phillip, which is great.
> 
> This topic, when merged to 'seen', seems to have quite a lot of
> overlaps with his pw/rebase-drop-notes-with-commit topic.

> We are
> expecting the topic to be rerolled, and I was under the impression
> that the remaining issues in that topic were all minor (Phillip,
> correct me if I am wrong) and hopefully we will see it in 'next'
> not in so distant future.

> So it might make sense for you to coordinate with Phillip, and wait
> for his topic to be merged to 'next'.  After that happens, you would
> prepare a merge commit of the other branch into f85a7e6620 (Start
> Git 2.56 cycle, 2026-07-06) or some other stable point, and rebuild
> this patch on top of it.  That way, it will be much less likely that
> I'd make stupid and unnecessary mismerges when attempting to
> integrate this topic into my tree.