Re: Aborting 'rebase main feat' removes unversioned files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Here's the output from Windows, where everything works as expected.

PS> git --version
git version 2.33.0.windows.2
PS> rm -re -fo *
PS> git init -b main
Initialized empty Git repository in C:/Users/ted/test/.git/
PS> git commit -m 'init' --allow-empty
[main (root-commit) ea4422d] init
PS> git checkout -b feat
Switched to a new branch 'feat'
PS> echo 123 > readme.txt
PS> git add readme.txt
PS> git commit -m 'txt=123'
[feat 82fe34b] txt=123
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 readme.txt
PS> git checkout main
Switched to branch 'main'
PS> echo 012 > readme.txt
PS> git status
On branch main
Untracked files:
  (use "git add <file>..." to include in what will be committed)
        readme.txt

nothing added to commit but untracked files present (use "git add" to track)
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
PS> git rebase --abort
fatal: No rebase in progress?

On Sat, Sep 4, 2021 at 11:58 AM Fedor Biryukov <fedor.birjukov@xxxxxxxxx> wrote:
>
> Just tested it on my MacBook. To my surprise, the file got deleted by
> 'git rebase main feat':
>
> 550$ git --version
> git version 2.33.0
>
> 551$ git init -b main
> Initialized empty Git repository in
> /Users/ted/workspace/git-abort-bug/test/.git/
>
> 552$ git commit -m 'init' --allow-empty
> [main (root-commit) ede7bdf] init
>
> 553$ git checkout -b feat
> Switched to a new branch 'feat'
>
> 554$ echo 123 > readme.txt
>
> 555$ git add readme.txt
>
> 556$ git commit -m 'txt=123'
> [feat 29ac3de] txt=123
>  1 file changed, 1 insertion(+)
>  create mode 100644 readme.txt
>
> 557$ git checkout main
> Switched to branch 'main'
>
> 558$ echo 012 > readme.txt
>
> 559$ git rebase main feat
> Current branch feat is up to date.
>
> 560$ git rebase --abort
> fatal: No rebase in progress?
>
> On Sat, Sep 4, 2021 at 11:51 AM Fedor Biryukov <fedor.birjukov@xxxxxxxxx> wrote:
> >
> > 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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux