Re: Aborting 'rebase main feat' removes unversioned files

Actually it's the same on all operating systems. I just forgot to add
a new base commit in main in the reproduction scenario - there was
nothing to rebase...
Here is the correct scenario along with the output.

+ git init -b main repo
Initialized empty Git repository in
/Users/ted/workspace/git-abort-bug/repo/.git/
+ cd repo
+ git commit -m base --allow-empty
[main (root-commit) 3299694] base
+ git checkout -b feat
Switched to a new branch 'feat'
+ echo feat >readme.txt
+ git add readme.txt
+ git commit -m txt=feat
[feat c9dc9b4] txt=feat
 1 file changed, 1 insertion(+)
 create mode 100644 readme.txt
+ git checkout main
Switched to branch 'main'
+ git commit -m new-base --allow-empty
[main c5c292c] new-base
+ echo precious > readme.txt
+ git rebase main feat
error: The following untracked working tree files would be overwritten by merge:
readme.txt
Please move or remove them before you merge.
Aborting
hint: Could not execute the todo command
hint:
hint:     pick c9dc9b4d5aca461f1a1bedd3b99b5c8533d5ef10 txt=feat
hint:
hint: It has been rescheduled; To edit the command before continuing, please
hint: edit the todo list first:
hint:
hint:     git rebase --edit-todo
hint:     git rebase --continue
Could not apply c9dc9b4... txt=feat
+ cat readme.txt
precious
+ git rebase --abort
+ cat readme.txt
feat

-Fedor

On Sat, Sep 4, 2021 at 12:24 PM Jeff King [off-list ref] wrote:

On Sat, Sep 04, 2021 at 12:03:49PM +0200, Fedor Biryukov wrote:

quoted

Here's the output from Windows, where everything works as expected.
[...]
PS> git rebase main feat
error: The following untracked working tree files would be overwritten
by checkout:
        readme.txt
Please move or remove them before you switch branches.
Aborting
error: could not detach HEAD

Interesting that it behaves differently than the mac and linux versions.
There are some changes between Git for Windows and regular upstream Git,
but looking over the diff between the v2.33.0 releases, I don't see
anything that might cause this discrepancy.

If the problem used to occur on v2.31 and now doesn't, it might be
interesting to bisect it.

-Peff