git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Phillip Wood <phillip.wood123@gmail.com>
To: Blaise Garant <blaise@garantcoutu.com>, git@vger.kernel.org
Subject: Re: rebase --abort Unespected behavior
Date: Sat, 29 Feb 2020 14:28:03 +0000	[thread overview]
Message-ID: <13cdf33b-7ca2-c391-fddd-53bdbae7f0d3@gmail.com> (raw)
In-Reply-To: <CANXsDork=bL=SUodXDzkcnjpPALm53e++UkVkJFWxaZPMBK-SQ@mail.gmail.com>

Hi Blaise

On 28/02/2020 17:36, Blaise Garant wrote:
> Hello,
> 
> I don't know if this is a bug but it was unexpected for us. I
> accidentally added untracked files through a `git add .` while doing
> an interactive rebase and aborting the rebase deleted those files. Is
> this to be expected?

I agree that this is surprising and undesirable but it's not unexpected 
given the way --abort is implemented. 'rebase --abort' calls 'reset 
--hard <branch we're rebasing>' so it will discard all the uncommitted 
changes in the worktree and reset the worktree and index to the branch tip.

The tricky thing with your situation is that the files are tracked at 
the point we call 'reset --hard' as they've been added to the index so 
git feels free to discard them. Perhaps rather than calling 'reset 
--hard' it would be better to use a custom callback with unpack_trees() 
that errors out if there are any paths in the index that are not in 
HEAD, the commit we just picked or the branch tip we're resetting to. If 
we do that we should consider using the same thing for 
'cherry-pick/merge/reset --abort' as well. --autostash potentially 
complicates things as the file might be in the stash but not in the 
other commits but lets not worry about that at the moment.

If your untracked files were ignored then I think 'git add .' would have 
complained or just not added them, but 'git checkout' and 'git merge' 
will happily overwrite ignored files so ignoring them is not always an 
ideal solution.

Best Wishes

Phillip


> To reproduce:
> mkdir test_folder
> cd test_folder
> git init
> touch first
> git add .
> git commit -m 'First'
> echo 1 >> first
> git add .
> git commit -m 'Second'
> echo 2 >> first
> git add .
> touch second
> git commit -m 'Third'
> git rebase -i HEAD~2 #set second to be edited
> git add .
> git status        #second should have staged
> git rebase --abort
> ls        #second has been deleted
> 
> Not sure this is an expected behavior.
> Thanks
> Blaise Garant
> 

  reply	other threads:[~2020-02-29 14:28 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-28 17:36 rebase --abort Unespected behavior Blaise Garant
2020-02-29 14:28 ` Phillip Wood [this message]
2020-02-29 15:51   ` Elijah Newren
2020-03-04 20:55     ` Phillip Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=13cdf33b-7ca2-c391-fddd-53bdbae7f0d3@gmail.com \
    --to=phillip.wood123@gmail.com \
    --cc=blaise@garantcoutu.com \
    --cc=git@vger.kernel.org \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).