threads / discuss / 50538

git rebase --continue after solving conflicts doesn't work anymore

Subject: git rebase --continue after solving conflicts doesn't work anymore

## tl;dr

9 messages between Feb 19, 2019 and Feb 19, 2019.

replies: 8people: 5as markdown or json

Sebastián Mancilla· Feb 19, 2019, 04:17 UTC · lore
I've always used "git rebase --continue" as the help shows:
    Resolve all conflicts manually, mark them as resolved with
    "git add/rm <conflicted_files>", then run "git rebase --continue".

and Git would apply the conflicted commit without issues and the rebase would continue.

But since Git 2.20.x it doesn't work anymore. Now after solving the conflicts and running "git rebase --continue" I get this error most of the time:

    error: unable to dequote value of 'GIT_AUTHOR_DATE'
    error: you have staged changes in your working tree
    If these changes are meant to be squashed into the previous commit, run:
      git commit --amend
    If they are meant to go into a new commit, run:
      git commit
    In both cases, once you're done, continue with:
      git rebase --continue
    error: could not commit staged changes.

Now I have to run "git commit" first to commit manually and then do the "git rebase --continue".

I've compiled 2.18.2 and 2.19.2 to check and the error doesn't happen.
It is present in 2.20.x and current master v2.21.0-rc1-9-gca1b411648.
Is it a regression because of the new rebase written in C?
-- 
Sebastian Mancilla
Christian Couder· Feb 19, 2019, 06:45 UTC · re: Sebastián Mancilla · lore

Re: git rebase --continue after solving conflicts doesn't work anymore

On Tue, Feb 19, 2019 at 5:20 AM Sebastián Mancilla <smancill.m@gmail.com> wrote:
Show 13 quoted lines
>
> I've always used "git rebase --continue" as the help shows:
>
>     Resolve all conflicts manually, mark them as resolved with
>     "git add/rm <conflicted_files>", then run "git rebase --continue".
>
> and Git would apply the conflicted commit without issues and the rebase would
> continue.
>
> But since Git 2.20.x it doesn't work anymore. Now after solving the conflicts
> and running "git rebase --continue" I get this error most of the time:
>
>     error: unable to dequote value of 'GIT_AUTHOR_DATE'

It looks like this can happen only when an "author-script" file (most likely .git/rebase-merge/author-script) is read by the sequencer mechanism. Could you show us the content of this file on your machine? It could also help if you could give us information about your OS and locale.

Show 24 quoted lines
>     error: you have staged changes in your working tree
>     If these changes are meant to be squashed into the previous commit, run:
>
>       git commit --amend
>
>     If they are meant to go into a new commit, run:
>
>       git commit
>
>     In both cases, once you're done, continue with:
>
>       git rebase --continue
>
>     error: could not commit staged changes.
>
> Now I have to run "git commit" first to commit manually and then do the "git
> rebase --continue".
>
> I've compiled 2.18.2 and 2.19.2 to check and the error doesn't happen.
>
> It is present in 2.20.x and current master v2.21.0-rc1-9-gca1b411648.
>
>
> Is it a regression because of the new rebase written in C?
That's possible.

Thanks for the report, Christian.

Eric Sunshine· Feb 19, 2019, 07:22 UTC · re: Christian Couder · lore

Re: git rebase --continue after solving conflicts doesn't work anymore

[cc:+phillip.wood@talktalk.net]

On Tue, Feb 19, 2019 at 1:45 AM Christian Couder <christian.couder@gmail.com> wrote:

Show 9 quoted lines
> On Tue, Feb 19, 2019 at 5:20 AM Sebastián Mancilla <smancill.m@gmail.com> wrote:
> > But since Git 2.20.x it doesn't work anymore. Now after solving the conflicts
> > and running "git rebase --continue" I get this error most of the time:
> >
> >     error: unable to dequote value of 'GIT_AUTHOR_DATE'
>
> It looks like this can happen only when an "author-script" file (most
> likely .git/rebase-merge/author-script) is read by the sequencer
> mechanism. Could you show us the content of this file on your machine?

A very good suggestion considering that there have been changes recently specifically related to the parsing of GIT_AUTHOR_DATE in C code.

Phillip Wood· Feb 19, 2019, 09:59 UTC · re: Eric Sunshine · lore

Re: git rebase --continue after solving conflicts doesn't work anymore

Dear Sebastián
On 19/02/2019 07:22, Eric Sunshine wrote:
> [cc:+phillip.wood@talktalk.net]
Thanks Eric
Show 10 quoted lines
> On Tue, Feb 19, 2019 at 1:45 AM Christian Couder
> <christian.couder@gmail.com> wrote:
>> On Tue, Feb 19, 2019 at 5:20 AM Sebastián Mancilla <smancill.m@gmail.com> wrote:
>>> But since Git 2.20.x it doesn't work anymore. Now after solving the conflicts
>>> and running "git rebase --continue" I get this error most of the time:
>>>
>>>      error: unable to dequote value of 'GIT_AUTHOR_DATE'
>>
>> It looks like this can happen only when an "author-script" file (most
>> likely .git/rebase-merge/author-script)

or it could be .git/rebase-apply/author-script depending on the options passed to rebase when it started (the sequencer and am use the same code for reading the author script now)

Show 6 quoted lines
>> is read by the sequencer
>> mechanism. Could you show us the content of this file on your machine?
> 
> A very good suggestion considering that there have been changes
> recently specifically related to the parsing of GIT_AUTHOR_DATE in C
> code.

That would be very helpful, without seeing that it's hard to know what the problem is.

Best Wishes
Phillip
Sebastián Mancilla· Feb 19, 2019, 14:03 UTC · re: Phillip Wood · lore

Re: git rebase --continue after solving conflicts doesn't work anymore

My system is macOS Mojave 10.14.2. I normally use Git from Homebrew (currently Git 2.20.1).

I investigated this further, and I think I found the problem on my end.

When I actually run "git rebase --interactive <commit>" from the terminal, everything works fine.

But almost every time I start my rebases from inside "tig" [0], for which I have this mapping:

        bind main R <git rebase -i %(commit)

tig will exit after running that command, and then I normally continue working on the rebase from the shell. And it is when I start the rebase this way that "git rebase --continue" fails after solving conflicts.

Second, I have tig installed with the Nix package manager [1], which shows
        $ ~/.nix-profile/bin/tig --version
        tig version 2.4.1
        ncursesw version 6.1.20180127
        readline version 6.3

So, I decided to try with tig from Homebrew, and then the problem doesn't happen. The Hombrew version of tig shows:

        $ /usr/local/bin/tig --version
        tig version 2.4.1
        ncurses version 5.7.20081102
        readline version 8.0
I will keep using tig from Homebrew to avoid issues for now.

In summary, the problem only happens when I start the rebase from inside tig, but only when tig is the version from the Nix package manager, which has different dependencies than the Homebrew version of tig. And it happens for Git 2.20.x and master. Git <= 2.19.x works fine.

I also did bisect Git (I never though I would be bisecting Git itself). It landed in this commit: 4d010a757c (sequencer: use read_author_script(), 2018-10-31).

And the content of .git/rebase-merge/author-script is always the same:
        GIT_AUTHOR_NAME='Sebastián Mancilla'
        GIT_AUTHOR_EMAIL='smancill@jlab.org'
        GIT_AUTHOR_DATE='@1550530007 -0300
Regards

[0]: https://github.com/jonas/tig [1]: https://nixos.org/nix/

El mar., 19 de feb. de 2019 a la(s) 06:59, Phillip Wood (phillip.wood@talktalk.net) escribió:

Show 37 quoted lines
>
> Dear Sebastián
>
> On 19/02/2019 07:22, Eric Sunshine wrote:
> > [cc:+phillip.wood@talktalk.net]
>
> Thanks Eric
>
> > On Tue, Feb 19, 2019 at 1:45 AM Christian Couder
> > <christian.couder@gmail.com> wrote:
> >> On Tue, Feb 19, 2019 at 5:20 AM Sebastián Mancilla <smancill.m@gmail.com> wrote:
> >>> But since Git 2.20.x it doesn't work anymore. Now after solving the conflicts
> >>> and running "git rebase --continue" I get this error most of the time:
> >>>
> >>>      error: unable to dequote value of 'GIT_AUTHOR_DATE'
> >>
> >> It looks like this can happen only when an "author-script" file (most
> >> likely .git/rebase-merge/author-script)
>
> or it could be .git/rebase-apply/author-script depending on the options
> passed to rebase when it started (the sequencer and am use the same code
> for reading the author script now)
>
> >> is read by the sequencer
> >> mechanism. Could you show us the content of this file on your machine?
> >
> > A very good suggestion considering that there have been changes
> > recently specifically related to the parsing of GIT_AUTHOR_DATE in C
> > code.
>
> That would be very helpful, without seeing that it's hard to know what
> the problem is.
>
> Best Wishes
>
> Phillip
>
-- 
Sebastian Mancilla
Duy Nguyen· Feb 19, 2019, 14:14 UTC · re: Sebastián Mancilla · lore

Re: git rebase --continue after solving conflicts doesn't work anymore

On Tue, Feb 19, 2019 at 9:04 PM Sebastián Mancilla <smancill.m@gmail.com> wrote:
Show 6 quoted lines
> And the content of .git/rebase-merge/author-script is always the same:
>
>         GIT_AUTHOR_NAME='Sebastián Mancilla'
>         GIT_AUTHOR_EMAIL='smancill@jlab.org'
>         GIT_AUTHOR_DATE='@1550530007 -0300
>

Just to be clear, the lack of closing quote on the last line is not a typo right?

-- 
Duy
Sebastián Mancilla· Feb 19, 2019, 14:25 UTC · re: Duy Nguyen · lore

Re: git rebase --continue after solving conflicts doesn't work anymore

No, it's not a typo. I just checked again.

That's the file that results when I start the rebase from tig (the Nix version), which results in the error for rebase --continue.

When I start the rebase manually or from tig (the Homebrew version) it has the quote.

        GIT_AUTHOR_NAME='Sebastián Mancilla'
        GIT_AUTHOR_EMAIL='smancill@jlab.org'
        GIT_AUTHOR_DATE='@1550530007 -0300'
Regards

El mar., 19 de feb. de 2019 a la(s) 11:15, Duy Nguyen (pclouds@gmail.com) escribió:

Show 13 quoted lines
>
> On Tue, Feb 19, 2019 at 9:04 PM Sebastián Mancilla <smancill.m@gmail.com> wrote:
> > And the content of .git/rebase-merge/author-script is always the same:
> >
> >         GIT_AUTHOR_NAME='Sebastián Mancilla'
> >         GIT_AUTHOR_EMAIL='smancill@jlab.org'
> >         GIT_AUTHOR_DATE='@1550530007 -0300
> >
>
> Just to be clear, the lack of closing quote on the last line is not a
> typo right?
> --
> Duy
-- 
Sebastian Mancilla
Christian Couder· Feb 19, 2019, 14:18 UTC · re: Sebastián Mancilla · lore

Re: git rebase --continue after solving conflicts doesn't work anymore

On Tue, Feb 19, 2019 at 3:03 PM Sebastián Mancilla <smancill.m@gmail.com> wrote:
Show 5 quoted lines
>
> My system is macOS Mojave 10.14.2. I normally use Git from Homebrew (currently
> Git 2.20.1).
>
> I investigated this further, and I think I found the problem on my end.
[...]
> I also did bisect Git (I never though I would be bisecting Git itself).
> It landed in this commit: 4d010a757c (sequencer: use read_author_script(),
> 2018-10-31).
Thanks for investigating this.
Show 5 quoted lines
> And the content of .git/rebase-merge/author-script is always the same:
>
>         GIT_AUTHOR_NAME='Sebastián Mancilla'
>         GIT_AUTHOR_EMAIL='smancill@jlab.org'
>         GIT_AUTHOR_DATE='@1550530007 -0300
When I look at such a file I get the following:
GIT_AUTHOR_DATE='@1549569954 -0800'

so it seems to me that a single quote is missing at the end of the line in your file, which might explain the error.

Not sure which software is writing this file, but from what you described it might be the tig you had previously installed.

Phillip Wood· Feb 19, 2019, 14:32 UTC · re: Sebastián Mancilla · lore

Re: git rebase --continue after solving conflicts doesn't work anymore

Hi Sebastián
On 19/02/2019 14:03, Sebastián Mancilla wrote:
Show 52 quoted lines
> My system is macOS Mojave 10.14.2. I normally use Git from Homebrew (currently
> Git 2.20.1).
> 
> I investigated this further, and I think I found the problem on my end.
> 
> When I actually run "git rebase --interactive <commit>" from the terminal,
> everything works fine.
> 
> But almost every time I start my rebases from inside "tig" [0], for which I
> have this mapping:
> 
>          bind main R <git rebase -i %(commit)
> 
> tig will exit after running that command, and then I normally continue working
> on the rebase from the shell. And it is when I start the rebase this way that
> "git rebase --continue" fails after solving conflicts.
> 
> Second, I have tig installed with the Nix package manager [1], which shows
> 
>          $ ~/.nix-profile/bin/tig --version
>          tig version 2.4.1
>          ncursesw version 6.1.20180127
>          readline version 6.3
> 
> So, I decided to try with tig from Homebrew, and then the problem
> doesn't happen.
> The Hombrew version of tig shows:
> 
>          $ /usr/local/bin/tig --version
>          tig version 2.4.1
>          ncurses version 5.7.20081102
>          readline version 8.0
> 
> I will keep using tig from Homebrew to avoid issues for now.
> 
> 
> In summary, the problem only happens when I start the rebase from inside tig,
> but only when tig is the version from the Nix package manager, which has
> different dependencies than the Homebrew version of tig.
> And it happens for Git 2.20.x and master. Git <= 2.19.x works fine.
> 
> 
> I also did bisect Git (I never though I would be bisecting Git itself).
> It landed in this commit: 4d010a757c (sequencer: use read_author_script(),
> 2018-10-31).
> 
> And the content of .git/rebase-merge/author-script is always the same:
> 
>          GIT_AUTHOR_NAME='Sebastián Mancilla'
>          GIT_AUTHOR_EMAIL='smancill@jlab.org'
>          GIT_AUTHOR_DATE='@1550530007 -0300
>

Thanks for all the details, the problem is that the older version of git that the Nix tig uses to start the rebase creates author scripts that are not correctly quoted (as you can see above) and cannot be read by the newer version of git you were using to continue the rebase (it should be possible to continue the rebase with the git bundled with Nix tig). Anyway I'm glad the Homebrew tig is working for you. When we made this change and discussed whether we needed backwards compatibility I think we only discussed the possibility of git being upgrading while a rebase was stopped for conflict resolution, not the possibility of people having two different versions of git installed and using one to start a rebase and the other to continue it.

Best Wishes
Phillip
Show 47 quoted lines
> Regards
> 
> 
> [0]: https://github.com/jonas/tig
> [1]: https://nixos.org/nix/
> 
> El mar., 19 de feb. de 2019 a la(s) 06:59, Phillip Wood
> (phillip.wood@talktalk.net) escribió:
>>
>> Dear Sebastián
>>
>> On 19/02/2019 07:22, Eric Sunshine wrote:
>>> [cc:+phillip.wood@talktalk.net]
>>
>> Thanks Eric
>>
>>> On Tue, Feb 19, 2019 at 1:45 AM Christian Couder
>>> <christian.couder@gmail.com> wrote:
>>>> On Tue, Feb 19, 2019 at 5:20 AM Sebastián Mancilla <smancill.m@gmail.com> wrote:
>>>>> But since Git 2.20.x it doesn't work anymore. Now after solving the conflicts
>>>>> and running "git rebase --continue" I get this error most of the time:
>>>>>
>>>>>       error: unable to dequote value of 'GIT_AUTHOR_DATE'
>>>>
>>>> It looks like this can happen only when an "author-script" file (most
>>>> likely .git/rebase-merge/author-script)
>>
>> or it could be .git/rebase-apply/author-script depending on the options
>> passed to rebase when it started (the sequencer and am use the same code
>> for reading the author script now)
>>
>>>> is read by the sequencer
>>>> mechanism. Could you show us the content of this file on your machine?
>>>
>>> A very good suggestion considering that there have been changes
>>> recently specifically related to the parsing of GIT_AUTHOR_DATE in C
>>> code.
>>
>> That would be very helpful, without seeing that it's hard to know what
>> the problem is.
>>
>> Best Wishes
>>
>> Phillip
>>
> 
>

← back to recent threads