Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"

[Jakub Narebski <jnareb@gmail.com>]

[This is git@vger.kernel.org only copy]

Junio C Hamano wrote:
> Olivier Marin <dkr+ml.git@free.fr> writes:
> 
>> It tries to apply patches even on a dirty tree which makes difficult
>> to automatically do a "git reset --hard" with --skip or --abort and
>> forces the user to clean the index by hand if last patch failed with
>> unmerged files.
>>
>> So, do some people still use "git am" with a dirty tree or will a
>> patch that make it work like "git rebase" be accepted?
> 
> Anything that changes "am" to require a clean working tree will NEVER be
> accepted.  I personally rely on the ability for it to run in a dirty tree,
> so does Linus.
> 
>       Side note.  Anything that changes "merge" to require a clean
>       working tree is also unacceptable.  Cf.
> 
>       http://thread.gmane.org/gmane.comp.version-control.git/9073/focus=9089
> 
>       Linus talks about "patch" in the paragraph second to the last one
>       in the message; back then he was talking about "git-applymbox" but
>       the same argument there applies to its newer incarnation "git-am".
> 
>       Side note #2.  It would have been nice if "rebase" were also
>       written in such a way that it can work in a dirty tree as long as
>       local changes did not interfere with the operation, but it is a
>       lot more involved.
> 
> When I looked at the "am --abort" patch briefly, I had an impression (by
> reading its test case) that it correctly refrained from doing the
> destructive "reset --hard".

I guess instead of "git reset --hard" we can use here "git stash save
&& git stash apply --index" to save state (perhaps as "git stash save
--no-reset"), and either "git stash drop" at the the end, or 
"git reset --hard && git stash pop --index" at '--abort'.

-- 
Jakub Narebski
Poland
ShadeHawk on #git