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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).