Re: Aborting 'rebase main feat' removes unversioned files

[Fedor Biryukov <fedor.birjukov@gmail.com>]

There is no way this could be the intended behavior, but the good news
is that I cannot reproduce it...
Looks like it occurs only in one git version (2.31.0.windows.1, IIRC).
And it does not occur in the latest git version: git version 2.33.0.windows.2.

-Fedor

On Sat, Sep 4, 2021 at 11:48 AM Jeff King <peff@peff.net> wrote:
>
> On Sat, Sep 04, 2021 at 01:57:11PM +0700, Bagas Sanjaya wrote:
>
> > On 04/09/21 03.33, Fedor Biryukov wrote:
> > > 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?
>
> I don't think so.
>
> The point is that "readme.txt" is not a tracked file on the main branch,
> and thus Git should consider it precious.
>
> I don't think the "rebase --abort" is the problem here, though. It's the
> command before:
>
>   git rebase main feat
>
> The "feat" branch is already ahead of "main" (which has no new commits),
> and so it just says:
>
>   Current branch feat is up to date.
>
> and leaves us on the "feat" branch. But in doing so, it overwrites the
> precious untracked content in the working tree.
>
> The "git rebase --abort" command then does nothing, because there's no
> rebase in progress.
>
> -Peff