Jonathan Nieder <jrnieder@xxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html