Hi,
Junio C Hamano wrote:
> Stephan Beyer <s-beyer@xxxxxxx> writes:
> > Junio C Hamano wrote:
> >> Olivier Marin <dkr+ml.git@xxxxxxx> writes:
> >> > @@ -203,9 +204,10 @@ then
> >> >
> >> > case "$abort" in
> >> > t)
> >> > - rm -fr "$dotest" &&
> >> > + git rerere clear &&
> >> > git read-tree -m -u ORIG_HEAD &&
> > [...]
> >> diff --git a/git-am.sh b/git-am.sh
> >> index a44bd7a..5cbf8f4 100755
> >> --- a/git-am.sh
> >> +++ b/git-am.sh
> >> @@ -203,9 +203,9 @@ then
> >>
> >> case "$abort" in
> >> t)
> >> - rm -fr "$dotest" &&
> >> - git read-tree -m -u ORIG_HEAD &&
> >> - git reset ORIG_HEAD && :
> >> + git rerere clear
> >> + git read-tree --reset -u HEAD ORIG_HEAD
> >
> > Perhaps I am confused, but ...
> > Why is there "HEAD" and "ORIG_HEAD" and not only "ORIG_HEAD"?
>
> Just being a bit defensive -- in this case I think it might be Ok to say
> "read-tree --reset -u ORIG_HEAD", but I haven't checked in a conflicted
> case.
Well, the test suite fails:
* FAIL 4: am --abort goes back after failed am
git-am --abort &&
git rev-parse HEAD >actual &&
git rev-parse initial >expect &&
test_cmp expect actual &&
here> test_cmp file-2-expect file-2 &&
... git diff-index --exit-code --cached HEAD &&
test ! -f .git/rr-cache/MERGE_RR
* FAIL 7: am --abort goes back after failed am -3
git-am --abort &&
git rev-parse HEAD >actual &&
git rev-parse initial >expect &&
test_cmp expect actual &&
and here> test_cmp file-2-expect file-2 &&
git diff-index --exit-code --cached HEAD &&
test ! -f .git/rr-cache/MERGE_RR
So no reason to be defensive ;)
> If some path was added between ORIG_HEAD (that is where we started from)
> and HEAD (that is where we are and we decide we do not want it), and that
> path is conflicted in the index, a single tree form "read-tree --reset -u
> HEAD" would leave it behind in the working tree, wouldn't it?
Seems so.
The reason of my question was that I *blindly* incorporated the change into
sequencer to make it able to work on a dirty working tree and thus to be
able to migrate am onto it without losing the ability to apply patches
on a dirty working tree....
All am tests applied afterwards, but the sequencer and the rebase-i
test suite failed in a place where I didn't expect it. I *then* had
a deeper look at the read-tree line and I was wondering what the "HEAD"
should achieve.
I removed it and all tests passed. (I didn't have t4151 in my branch
at that point.)
Now, because t4151 does not pass, I am wondering what's the best thing
I could do...
Regards,
Stephan
--
Stephan Beyer <s-beyer@xxxxxxx>, PGP 0x6EDDD207FCC5040F
--
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
