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

Reply via email to