mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Elijah Newren <>
To: Eugen Konkov <>
Cc: Git Mailing List <>,
	Thomas Gummerer <>,
	Johannes Schindelin <>
Subject: Re: git rebase/git rebase --abort cause inconsistent state
Date: Fri, 6 Nov 2020 12:27:08 -0800	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Nov 6, 2020 at 10:41 AM Eugen Konkov <> wrote:
> Hi
> I try to rebase, get conflicts. So I decide to --abort
> After --abort I expect state before rebasing, but I get conflicts.
> I  suppose this  is  because `git rebase` switches to not branch and
> --abort can not return to branch I was on before rebasing
> Is this a bug?
> kes@work ~/t/lib/MaitreD $ git rebase dev local/dev
> Created autostash: 566876c8
> warning: Cannot merge binary files: share/ChangeAgreement.docx (HEAD vs. f2442d9a... Update
> Auto-merging share/ChangeAgreement.docx
> CONFLICT (content): Merge conflict in share/ChangeAgreement.docx
> error: could not apply f2442d9a... Update
> Resolve all conflicts manually, mark them as resolved with
> "git add/rm <conflicted_files>", then run "git rebase --continue".
> You can instead skip this commit: run "git rebase --skip".
> To abort and get back to the state before "git rebase", run "git rebase --abort".
> Could not apply f2442d9a... Update
> kes@work ~/t/lib/MaitreD $ git rebase --abort
> Applying autostash resulted in conflicts.

Looks like you have rebase.autostash set to true and have some
uncommitted changes before your rebase started; it looks like it was
the reapplying of that stash at the time you abort is the thing that

According to the rebase docs for the --abort flag:
"If <branch> was provided when the rebase operation was started, then
HEAD will be reset to <branch>"
which suggests that the abort should switch you back to the original
branch, where the application of your local changes should be safe.
I'll cc the two most prolific committers to builtin/stash.c to get
their comments.

Some questions they may be interested in, though:  Is this bug
repeatable?  Can you find steps to reproduce and/or share your
repository?  Can you verify that you don't get this bug when
rebase.autostash is off?  What do your local changes before the rebase
look like and what are the nature of the conflicts afterwards (how
does a "git diff" before the rebase compare to a "git diff" after)?

> Your changes are safe in the stash.
> You can run "git stash pop" or "git stash drop" at any time.
> Here is a tree before rebasing:
> > a9597aaa (HEAD -> dev) Use DateTime with correct timezone
> > 822ff801 Add link to Podio into mail
> > 65575afe Update
> | < e0003861 (local/dev) Update podio.t - test person contacts
> | < 28ab8630 Create docdate if agreement is new and update test for that
> | < 208ead68 Specified checking of person
> | < f2442d9a Update
> |/
> o 6d9c2159 (xtucha/test, xtucha/dev) Leave only one example in month
> Here is conflicts:
> HEAD detached from 142c1b15
> Changes to be committed:
>   (use "git restore --staged <file>..." to unstage)
> 1       modified:   ../../Makefile
> 2       modified:   ../../etc/maitre_d.development.conf
> 3       modified:   Command/
> 4       modified:   Command/
> 5       modified:   Command/
> 6       modified:   Controller/
> 7       modified:   Controller/
> Unmerged paths:
>   (use "git restore --staged <file>..." to unstage)
>   (use "git add <file>..." to mark resolution)
> 8       both modified:   Controller/
> $ git --version
> git version 2.28.0
> --
> Best regards,
> Eugen Konkov

  parent reply	other threads:[~2020-11-06 20:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-06 18:32 git rebase/git rebase --abort cause inconsistent state Eugen Konkov
2020-11-06 18:34 ` Eugen Konkov
2020-11-06 20:27 ` Elijah Newren [this message]
2020-11-06 23:13   ` Johannes Sixt
2020-11-09 11:46     ` Eugen Konkov
2020-11-09 18:11       ` Junio C Hamano
2020-11-10 17:59         ` Eugen Konkov
2020-11-10 22:28         ` Johannes Schindelin
2020-11-11  7:10           ` Johannes Sixt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).