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

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

 



On Thu, Jul 4, 2013 at 3:35 PM, Paul A. Kennedy <pakenned@xxxxxxxxx> wrote:
> 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]).
> +

Not commenting about the change in general, just one issue: The
transition to "dangling blobs" seems abrupt and may convey little
meaning to non-expert users. Perhaps lead in to that sentence with
something along the lines of:

  "If you neglect to unstage untracked files before abort, they become
dangling blogs, which may be found ..."

Also, a bit earlier, perhaps: s/Unstage files/Manually unstage files/
--
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]