On 24/07/2025 23:03, Junio C Hamano wrote:
Cameron Steffen <cam.steffen94@xxxxxxxxx> writes:
Sometimes I run into a conflict in a rebase and I end up resolving the
conflict by removing all the changes. Then when I run `git rebase
--continue`, the current commit is skipped and the rebase continues
normally. Would it be possible to emit a message showing that the
commit was skipped in this case? It isn't very obvious to me in my
workflow that that is what occurred.
I do not know what level of verbosity is needed to grab attention by
the end user, but something like this might be a good starting
point?
Totally untested, and there may be implications (like, control
passes this point in different situations where the messages is not
warranted).
I haven't tested it but I suspect this prints the warning when
continuing after a "break" command or a failed "exec" command. That is
probably a good place to issue such a message but we'd want to check
whether rebase_path_message() exists before printing the message. I
think we could also read REBASE_HEAD to find out which commit we're
skipping if we wanted to make the message a bit more informative.
It would mean that "rebase --skip" also prints this warning but I think
that is sensible if we're doing it for "rebase --continue" after
removing all the uncommitted changes from the worktree.
Thanks
Phillip
I'll pick a few people from
git shortlog --since=2.years --no-merges sequencer.c
based on their contribution to the file (not counting the internal
implementation changes) and Cc them to see if they have ideas.
Thanks.
sequencer.c | 2 ++
1 file changed, 2 insertions(+)
diff --git c/sequencer.c w/sequencer.c
index 67e4310edc..677d6105dd 100644
--- c/sequencer.c
+++ w/sequencer.c
@@ -5369,6 +5369,8 @@ static int commit_staged_changes(struct repository *r,
goto out;
}
+ warning(_("omitting a step that has become empty"));
+
if (!final_fixup) {
ret = 0;
goto out;
