From: Johannes Sixt <j6t@kdbg.org>
To: Elijah Newren <newren@gmail.com>, Eugen Konkov <kes-kes@yandex.ru>
Cc: Git Mailing List <git@vger.kernel.org>,
Thomas Gummerer <t.gummerer@gmail.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: git rebase/git rebase --abort cause inconsistent state
Date: Sat, 7 Nov 2020 00:13:04 +0100 [thread overview]
Message-ID: <43de6950-a33c-f3da-2a76-72719fef5af3@kdbg.org> (raw)
In-Reply-To: <CABPp-BGAJiaU5aeC3sGvp3znQw1esrn9c19gyOZQBymYvNFCaw@mail.gmail.com>
Am 06.11.20 um 21:27 schrieb Elijah Newren:
> On Fri, Nov 6, 2020 at 10:41 AM Eugen Konkov <kes-kes@yandex.ru> wrote:
>> 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 Docs.pm)
>> Auto-merging share/ChangeAgreement.docx
>> CONFLICT (content): Merge conflict in share/ChangeAgreement.docx
>> error: could not apply f2442d9a... Update Docs.pm
>> 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 Docs.pm
>> 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
> failed.
>
> 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.
Unfortunately, that is not always the case, for example, in this one.
>> 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 Docs.pm
>> | < 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 Docs.pm
>> |/
>> o 6d9c2159 (xtucha/test, xtucha/dev) Leave only one example in month
You start at branch dev. Then you use the two argument form
git rebase dev local/dev
and when you later
git rebase --abort
then you are not warped back to dev, but to local/dev:
> history after --abort:
> * e0003861 (HEAD, 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 Docs.pm
> * 6d9c2159 (xtucha/test, xtucha/dev) Leave only one example in month
and at this point, your stashed changes, which were snapshot when you
were on branch dev, are obvously in conflict with branch local/dev.
I'm not saying that that the behavior should be like this, I'm just
explaining what was going on. I hate this behavior, BTW.
-- Hannes
next prev parent reply other threads:[~2020-11-06 23:13 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
2020-11-06 23:13 ` Johannes Sixt [this message]
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=43de6950-a33c-f3da-2a76-72719fef5af3@kdbg.org \
--to=j6t@kdbg.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=kes-kes@yandex.ru \
--cc=newren@gmail.com \
--cc=t.gummerer@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://80x24.org/mirrors/git.git
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).