From: Jakub Narebski Date: Sat, 19 Jul 2008 22:39:12 GMT Subject: Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge" Message-ID: In-Reply-To: <7vd4l9zgmp.fsf@gitster.siamese.dyndns.org> [This is git@vger.kernel.org only copy] Junio C Hamano wrote: > Olivier Marin 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