On Wed, Jul 03, 2013 at 04:04:23PM -0700, Junio C Hamano wrote:
> Jonathan Nieder <[email protected]> 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
[email protected]
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
