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

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jul 4, 2013, 23:27 UTC
Message-ID: <CAPig+cSz2MH4REJyNDox_NCM3DnFamizzMMiDzX=SumpDL77Gw@mail.gmail.com>
In-Reply-To: <20130704193550.GA4183@localhost.localdomain>

On Thu, Jul 4, 2013 at 3:35 PM, Paul A. Kennedy <pakenned@pobox.com> wrote:

Show 15 quoted lines

> 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/