[This is git@xxxxxxxxxxxxxxx only copy] Junio C Hamano wrote: > Olivier Marin <dkr+ml.git@xxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
