threads / discuss / 63838

Show skipped commit message after rebase conflict?

Subject: Show skipped commit message after rebase conflict?

## tl;dr

11 messages between Jul 24, 2025 and Jul 26, 2025.

replies: 10people: 4as markdown or json

Cameron Steffen· Jul 24, 2025, 14:43 UTC · lore

Hello Git Community!

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.

Thanks, Cameron Steffen

Junio C Hamano· Jul 24, 2025, 22:03 UTC · re: Cameron Steffen · lore

Re: Show skipped commit message after rebase conflict?

Cameron Steffen <cam.steffen94@gmail.com> writes:

Show 6 quoted lines

> 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'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;

Phillip Wood· Jul 25, 2025, 14:02 UTC · re: Junio C Hamano · lore

Re: Show skipped commit message after rebase conflict?

On 24/07/2025 23:03, Junio C Hamano wrote:

Show 16 quoted lines

> Cameron Steffen <cam.steffen94@gmail.com> 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

Show 26 quoted lines

> 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;
>

Cameron Steffen· Jul 25, 2025, 14:14 UTC · re: Phillip Wood · lore

Re: Show skipped commit message after rebase conflict?

There is already a message that prints in the case where a commit is automatically skipped if the changes are already applied.

> warning: skipped previously applied commit <hash>

Potentially we could use the very same message.

On Fri, Jul 25, 2025 at 9:02 AM Phillip Wood <phillip.wood123@gmail.com> wrote:

Show 61 quoted lines

>
> On 24/07/2025 23:03, Junio C Hamano wrote:
> > Cameron Steffen <cam.steffen94@gmail.com> 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;
> >
>

Junio C Hamano· Jul 25, 2025, 14:40 UTC · re: Cameron Steffen · lore

Re: Show skipped commit message after rebase conflict?

Cameron Steffen <cam.steffen94@gmail.com> writes:

Show 6 quoted lines

> There is already a message that prints in the case where a commit is
> automatically skipped if the changes are already applied.
>
>> warning: skipped previously applied commit <hash>
>
> Potentially we could use the very same message.

Yes, that sounds like going in the right direction.

But only if we can positively tell the reason why there is no change relative to the parent commit _is_ because the commit we are currently picking has already been applied, that is.

I am not sure how you determine that, especially after giving control back the end user upon conflict.

Thanks.

Cameron Steffen· Jul 25, 2025, 15:20 UTC · re: Junio C Hamano · lore

Re: Show skipped commit message after rebase conflict?

> But only if we can positively tell the reason why there is no change

relative to the parent commit _is_ because the commit we are currently picking has already been applied, that is.

I thought we merely would need to see that there are no staged changes to be committed, and there is a currently-picking commit that will now be skipped? I don't need to know whether the commit was already applied. I just want to know that the commit in the rebase plan is not being committed.

On Fri, Jul 25, 2025 at 9:40 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 20 quoted lines

>
> Cameron Steffen <cam.steffen94@gmail.com> writes:
>
> > There is already a message that prints in the case where a commit is
> > automatically skipped if the changes are already applied.
> >
> >> warning: skipped previously applied commit <hash>
> >
> > Potentially we could use the very same message.
>
> Yes, that sounds like going in the right direction.
>
> But only if we can positively tell the reason why there is no change
> relative to the parent commit _is_ because the commit we are
> currently picking has already been applied, that is.
>
> I am not sure how you determine that, especially after giving
> control back the end user upon conflict.
>
> Thanks.

Junio C Hamano· Jul 26, 2025, 00:04 UTC · re: Cameron Steffen · lore

Re: Show skipped commit message after rebase conflict?

Cameron Steffen <cam.steffen94@gmail.com> writes:

Show 9 quoted lines

>> But only if we can positively tell the reason why there is no change
> relative to the parent commit _is_ because the commit we are
> currently picking has already been applied, that is.
>
> I thought we merely would need to see that there are no staged changes
> to be committed, and there is a currently-picking commit that will now
> be skipped? I don't need to know whether the commit was already
> applied. I just want to know that the commit in the rebase plan is not
> being committed.

Then your earlier idea to reuse the same message

>> warning: skipped previously applied commit <hash>
>
> Potentially we could use the very same message.

would not work, would it?

Cameron Steffen· Jul 26, 2025, 02:40 UTC · re: Junio C Hamano · lore

Re: Show skipped commit message after rebase conflict?

I see what you mean now. I guess I did not consider the meaning of that message very closely.

On Fri, Jul 25, 2025 at 7:04 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 20 quoted lines

>
> Cameron Steffen <cam.steffen94@gmail.com> writes:
>
> >> But only if we can positively tell the reason why there is no change
> > relative to the parent commit _is_ because the commit we are
> > currently picking has already been applied, that is.
> >
> > I thought we merely would need to see that there are no staged changes
> > to be committed, and there is a currently-picking commit that will now
> > be skipped? I don't need to know whether the commit was already
> > applied. I just want to know that the commit in the rebase plan is not
> > being committed.
>
> Then your earlier idea to reuse the same message
>
> >> warning: skipped previously applied commit <hash>
> >
> > Potentially we could use the very same message.
>
> would not work, would it?

Johannes Sixt· Jul 26, 2025, 07:00 UTC · re: Cameron Steffen · lore

Re: Show skipped commit message after rebase conflict?

Am 25.07.25 um 17:20 schrieb Cameron Steffen:

Show 9 quoted lines

>> But only if we can positively tell the reason why there is no change
>> relative to the parent commit _is_ because the commit we are
>> currently picking has already been applied, that is.
> 
> I thought we merely would need to see that there are no staged changes
> to be committed, and there is a currently-picking commit that will now
> be skipped? I don't need to know whether the commit was already
> applied. I just want to know that the commit in the rebase plan is not
> being committed.

How would rebase know what I did while I had control? I could have fixed the conflicts and committed manually. I could have reset to a different commit. I could have split the change into two commits. I could have removed the changes. I could have made additional changes. Possibilities are unlimited. Saying something like "commit 123abc is now empty" or "is skipped" would be incorrect most of the time in my workflow.

-- Hannes

Cameron Steffen· Jul 26, 2025, 15:00 UTC · re: Johannes Sixt · lore

Re: Show skipped commit message after rebase conflict?

> I could have fixed the conflicts and committed manually.

I believe we can detect any case where you ran `git commit`. I just know that when you run git commit in that case the commit message is _not_ auto populated from the pending commit. So git seems to be aware if you did any commit that "replaces" the pending commit. So I think that addresses most of the cases you mentioned. As long as the first `git commit` after pausing from conflicts is non-empty, we can say the pending commit is not "skipped".

> I could have reset to a different commit.

I think it would be okay to emit the message if you hard reset and continue.

On Sat, Jul 26, 2025 at 2:00 AM Johannes Sixt <j6t@kdbg.org> wrote:

Show 21 quoted lines

>
> Am 25.07.25 um 17:20 schrieb Cameron Steffen:
> >> But only if we can positively tell the reason why there is no change
> >> relative to the parent commit _is_ because the commit we are
> >> currently picking has already been applied, that is.
> >
> > I thought we merely would need to see that there are no staged changes
> > to be committed, and there is a currently-picking commit that will now
> > be skipped? I don't need to know whether the commit was already
> > applied. I just want to know that the commit in the rebase plan is not
> > being committed.
>
> How would rebase know what I did while I had control? I could have fixed
> the conflicts and committed manually. I could have reset to a different
> commit. I could have split the change into two commits. I could have
> removed the changes. I could have made additional changes. Possibilities
> are unlimited. Saying something like "commit 123abc is now empty" or "is
> skipped" would be incorrect most of the time in my workflow.
>
> -- Hannes
>

Junio C Hamano· Jul 25, 2025, 15:24 UTC · re: Phillip Wood · lore

Re: Show skipped commit message after rebase conflict?

Phillip Wood <phillip.wood123@gmail.com> writes:

> 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

Ah, such a test intuitively feels correct. We are not creating a commit, yet, we have message from the iteration being polished to use when we do create one, which is about to be lost. The user deserves to be notified of the lossage.

Show 6 quoted lines

> 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.

Would --skip even pass this spot in the code by calling commit_staged_changes()?

I am not intimately familiar with the way how the sequencer code is organized, and am navigating largely by guesses on names of functions and variables (iow, I didn't check).

Thanks.

Show 25 quoted lines

>
> 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;
>>