Re: Aborting 'rebase main feat' removes unversioned files

From: Bagas Sanjaya <bagasdotme@gmail.com>
Date: Sep 4, 2021, 06:57 UTC
Message-ID: <dbe7d88d-4174-e080-03df-e35d0ac6004f@gmail.com>
In-Reply-To: <C357A648-8B13-45C3-9388-C0C7F7D40DAE@gmail.com>

On 04/09/21 03.33, Fedor Biryukov wrote:

Show 14 quoted lines

> Looks like a bug in git rebase main feat.
> 
> To reproduce:
> git init
> git commit -m 'init' --allow-empty
> git checkout -b feat
> echo 123 > readme.txt
> git add readme.txt
> git commit -m 'txt=123'
> git checkout main
> echo 012 > readme.txt
> git rebase main feat
> git rebase --abort
>

Did you forget committing?

Show 7 quoted lines

> Expected result:
> readme.txt contains 012
> 
> Actual result:
> readme.txt contains 123
> 
> According to the docs, git rebase main feat is a shorthand for git checkout feat followed by git rebase main. I have checked that doing checkout and rebase separately instead of using the shorthand does not have the same issue.

I think this is non-issue (behavior as intended).

So when you say `git rebase main feat`, Git will rebase your commits in feat on top of main. If any conflicts occur and you abort rebasing (`git rebase --abort`), your feat branch just looks like before rebasing.

-- 
An old man doll... just what I always wanted! - Clara