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". -- 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
