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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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]).
 
 --keep-empty::
 	Keep the commits that do not change anything from its
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]