Show skipped commit message after rebase conflict?

Show skipped commit message after rebase conflict?

[Cameron Steffen]

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

Re: Show skipped commit message after rebase conflict?

[Junio C Hamano]

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

Re: Show skipped commit message after rebase conflict?

[Phillip Wood]

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

Re: Show skipped commit message after rebase conflict?

[Cameron Steffen]

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

Re: Show skipped commit message after rebase conflict?

[Junio C Hamano]

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.

Re: Show skipped commit message after rebase conflict?

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

On Fri, Jul 25, 2025 at 9:40 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> 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.

Re: Show skipped commit message after rebase conflict?

[Junio C Hamano]

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?

Re: Show skipped commit message after rebase conflict?

[Cameron Steffen]

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:
>
> 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?

Re: Show skipped commit message after rebase conflict?

[Johannes Sixt]

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

Re: Show skipped commit message after rebase conflict?

[Cameron Steffen]

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

Re: Show skipped commit message after rebase conflict?

[Junio C Hamano]

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.

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

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