Re: unexpected file deletion after using git rebase --abort

From: Paul A. Kennedy <pakenned@pobox.com>
Date: Jul 4, 2013, 19:35 UTC
Message-ID: <20130704193550.GA4183@localhost.localdomain>
In-Reply-To: <7vip0rckjs.fsf@alter.siamese.dyndns.org>

On Wed, Jul 03, 2013 at 04:04:23PM -0700, Junio C Hamano wrote:

Show 25 quoted lines

> Jonathan Nieder <jrnieder@gmail.com> writes:
> > Paul A. Kennedy wrote:
> > > If we don't expect this, should we update the documentation for the
> > > --abort heading in the git rebase man page to indicate that newly
> > > staged content will be lost after a git rebase --abort?
> >
> > How about something along these lines?
> >
> > diff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt
> > index 6b2e1c8..dcae40d 100644
> > --- i/Documentation/git-rebase.txt
> > +++ w/Documentation/git-rebase.txt
> > @@ -240,6 +240,9 @@ leave out at most one of A and B, in which case it defaults to HEAD.
> >  	started, then HEAD will be reset to <branch>. Otherwise HEAD
> >  	will be reset to where it was when the rebase operation was
> >  	started.
> > ++
> > +This discards any changes to files tracked in the working tree or <branch>.
> > +You may want to stash your changes first (see linkgit:git-stash[1]).
> >  
> 
> "rebase --abort" is typically used to get rid of conflicted mess the
> user does not want to resolve right now, and "stash" would not be a
> sensible thing to use in such a situation, I think.  Doesn't it even
> refuse to work if there is a conflicted entry in the index?

Thanks for thinking about this with me.

After contemplating your messages, I think that it's unreasonable to expect git rebase --abort to be able to properly handle content from completely outside the repo and only placed in the index.

I think that Jonathan's suggestion makes too mild a point (and I think Junio's objection may be a consequence of this). I've added a little paragraph to the documentation that covers two cases: what you should do before you started (i.e. git-stash if messing about with adding content); and how to recover in case you managed to "lose" content in this way (hence the links to git-fsck and git-cat-file).

This is the diff (against v.1.8.3.2 in the git tree):

diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index aca8405..ffaef29 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
@@ -238,6 +238,13 @@ leave out at most one of A and B, in which case it defaults to HEAD.
 	will be reset to where it was when the rebase operation was
 	started.
 
+	Untracked files added to the index will not be unstaged, and
+	therefore, not present in the working directory upon abort.
+	Unstage files before the abort, or stash untracked content before
+	starting the rebase (see linkgit:git-stash[1]).  Dangling blobs
+	may be found and recovered using fsck and cat-file (see
+	linkgit:git-fsck[1], linkgit:git-cat-file[1]).
+
 --keep-empty::
 	Keep the commits that do not change anything from its
 	parents in the result.

--
Paul A. Kennedy
pakenned@pobox.com