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@xxxxxxxx> 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
