From: "Paul A. Kennedy" <pakenned@pobox.com>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>,
Jonathan Nieder <jrnieder@gmail.com>,
"Paul A. Kennedy" <pakenned@pobox.com>
Subject: Re: unexpected file deletion after using git rebase --abort
Date: Thu, 4 Jul 2013 15:35:51 -0400 [thread overview]
Message-ID: <20130704193550.GA4183@localhost.localdomain> (raw)
In-Reply-To: <7vip0rckjs.fsf@alter.siamese.dyndns.org>
On Wed, Jul 03, 2013 at 04:04:23PM -0700, Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@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?
Thanks for thinking about this with me.
After contemplating your messages, I think that it's unreasonable to
expect git rebase --abort to be able to properly handle content from
completely outside the repo and only placed in the index.
I think that Jonathan's suggestion makes too mild a point (and I
think Junio's objection may be a consequence of this). I've added a
little paragraph to the documentation that covers two cases: what you
should do before you started (i.e. git-stash if messing about with
adding content); and how to recover in case you managed to "lose"
content in this way (hence the links to git-fsck and git-cat-file).
This is the diff (against v.1.8.3.2 in the git tree):
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]).
+
--keep-empty::
Keep the commits that do not change anything from its
parents in the result.
--
Paul A. Kennedy
pakenned@pobox.com
next prev parent reply other threads:[~2013-07-04 19:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-03 22:44 unexpected file deletion after using git rebase --abort Paul A. Kennedy
2013-07-03 22:56 ` Jonathan Nieder
2013-07-03 23:04 ` Junio C Hamano
2013-07-04 19:35 ` Paul A. Kennedy [this message]
2013-07-04 23:27 ` Eric Sunshine
2013-07-05 7:07 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130704193550.GA4183@localhost.localdomain \
--to=pakenned@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.