From: "Farid Zakaria" <farid.m.zakaria@gmail.com>
To: "Phillip Wood" <phillip.wood123@gmail.com>,
"Junio C Hamano" <gitster@pobox.com>,
"Farid Zakaria" <farid.m.zakaria@gmail.com>
Cc: <git@vger.kernel.org>,
"Phillip Wood" <phillip.wood@dunelm.org.uk>,
"Elijah Newren" <newren@gmail.com>,
"Patrick Steinhardt" <ps@pks.im>
Subject: Re: [PATCH v3] sequencer: honor --empty when a fixup!/squash! empties its target
Date: Mon, 13 Jul 2026 09:30:40 -0700 [thread overview]
Message-ID: <DJXL4KSUEAD4.1EE4ERHJZ00TR@gmail.com> (raw)
In-Reply-To: <7a1e5111-185e-4390-afa1-c19908c9bd86@gmail.com>
On Mon Jul 13, 2026 at 6:18 AM PDT, Phillip Wood wrote:
> On 12/07/2026 06:01, Junio C Hamano wrote:
>> 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.
>
> Oh, I should have thought of that
>
>> 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.
>
> I've just sent a new version and cc'd Farid, I'll try and take look at
> this patch tomorrow
>
Thanks for cc'd. I'm not familiar with the workflow (I read the docs)
but is there an email reply when it's accepted into 'next' that I will
just look-out for ? I'm not subscribed to the mailing list in general
otherwise.
>> 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.
>
> That makes sense, assuming no-one has any more comments on
> 'pw/rebase-drop-notes-with-commit' it should in be 'next' fairly soon.
>
> Thanks
>
> Phillip
Phillip,
Let me know if you have any more comments. I suspect not much will
changes logic-wise once I rebase it onto 'next'.
For clarity, is the f85a7e6620 commit the 'next' branch ? I would have
thought to just rebase ontop of 'next' and I'm a bit confused with this
commit hash.
If there is anything else I should be aware of, I would appreciate a CC
if you can remember :)
Thank you!
prev parent reply other threads:[~2026-07-13 16:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-12 0:38 [PATCH v3] sequencer: honor --empty when a fixup!/squash! empties its target Farid Zakaria
2026-07-12 5:01 ` Junio C Hamano
2026-07-13 13:18 ` Phillip Wood
2026-07-13 16:30 ` Farid Zakaria [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DJXL4KSUEAD4.1EE4ERHJZ00TR@gmail.com \
--to=farid.m.zakaria@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=phillip.wood@dunelm.org.uk \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.