"Paul A. Kennedy" 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 the
On Thu, Jul 4, 2013 at 3:35 PM, Paul A. Kennedy 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 wh
On Wed, Jul 03, 2013 at 04:04:23PM -0700, Junio C Hamano wrote:
> Jonathan Nieder 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 a
Jonathan Nieder 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?
>
>
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.
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 t
6 matches
Mail list logo
