git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: --no-edit not respected after conflict

From
Elijah Newren <newren@gmail.com>
Date
Mar 22, 2021, 17:14 UTC
Message-ID
<CABPp-BGZebutsk5c4kf9gAuu0zgSEptxRmbEBFFwNPE03D4R1g@mail.gmail.com>
In-Reply-To
<78c7bd2c-c487-756e-c85d-dcfe2866f5f4@FreeBSD.org>
On Mon, Mar 22, 2021 at 6:09 AM Renato Botelho <garga@freebsd.org> wrote:
Show 49 quoted lines
>
> On 19/03/21 18:30, brian m. carlson wrote:
> > On 2021-03-19 at 14:44:30, Renato Botelho wrote:
> >> I was reverting multiple commits using --no-edit parameter and after one of
> >> those commits conflicted and I resolved using mergetool, no-edit option was
> >> not respected anymore and next commits opened editor for me to review commit
> >> message.
> >
> > I'm not sure I understand what you're seeing here, and I think maybe if
> > I knew that I could provide more useful information.  Could you maybe
> > provide the set of commands that you're running up to and when you see
> > this problem, or even better, a reproduction testcase?
> >
>
> I ran `git revert --no-edit commit1 commit2 ... commitN` and one of
> those reverts had a conflict and the process stopped waiting for a
> resolution.
>
> I ran `git mergetool` and resolved the conflict, then ran `git revert
> --continue` and then it ignored --no-edit parameter for all other
> commits and opened $EDITOR for me to edit commit message.
>
> I managed to reproduce it on a testing repository doing following steps:
>
> % echo a > file
> % git init
> % git add file
> % git commit -m a
> % echo b > file; git commit -a -m b
> % echo c > file; git commit -a -m c
> % echo d > file; git commit -a -m d
> % echo e > file; git commit -a -m e
> % git log --oneline
>
> d3ec7fc e
> 23ad2b7 d
> 2265c82 c
> 5e0c98a b
> b34f81a a
>
> % git revert --no-edit d3ec7fc 2265c82 5e0c98a
>
> It will revert d3ec7fc without any interaction, as expected, then will
> stop the process on 2265c82 due to conflict and after resolve conflict
> when I do:
>
> % git revert --continue
>
> --no-edit parameter will be ignored when reverting 5e0c98a.
Thanks for the testcase.  I can reproduce.

sequencer.c:save_opts() will only save non-zero values (and since options.edit defaults to 1, it'll only save the default value).

sequencer.c:continue_single_pick() was written assuming struct replay_opts was not necessary, so even if opts->edit is 0, it just runs a plain "git commit" anyway. It should include --no-edit --cleanup=strip.

I've got a patch that fixes both issues, but need to make a proper testcase and whatnot. Maybe I'll have time to do that tonight.

Previous: Renato BotelhoNext: Elijah Newren
Message 4 of 8 in “--no-edit not respected after conflict”
  1. Renato BotelhoMar 19, 2021
  2. brian m. carlsonMar 19, 2021
  3. Renato BotelhoMar 22, 2021
  4. Elijah NewrenMar 22, 2021
  5. Elijah NewrenMar 24, 2021
  6. Junio C HamanoMar 24, 2021
  7. Elijah NewrenMar 26, 2021
  8. Renato BotelhoMar 26, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.