Paul A. Kennedy paken...@pobox.com writes:
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
On Wed, Jul 03, 2013 at 04:04:23PM -0700, Junio C Hamano wrote:
Jonathan Nieder jrnie...@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
On Thu, Jul 4, 2013 at 3:35 PM, Paul A. Kennedy paken...@pobox.com 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
Hello!
I lost a previously untracked file that I added to the index in the
middle of a git rebase --interactive session after a git rebase --abort.
This was unexpected.
$ ls forgotten_file
forgotten_file
$ git rebase --interactive HEAD~3
[change first rebase command from pick
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
Jonathan Nieder jrnie...@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
6 matches
Mail list logo
