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.
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?
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 [off-list ref], PGP 0x6EDDD207FCC5040F
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.
git read-tree --reset -u ORIG_HEAD clears local changes which is not good.
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 &&
Local changes have been lost.
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....
Are you talking about your seq-proto-dev3 branch?
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...
I looked at your code. You use reset_almost_hard() instead of "reset --hard",
it's fine but you does not update require_clean_work_tree() to be less
restrictive and let the sequencer work with local modifications. Those two
lines must be removed, I think:
git update-index --ignore-submodules --refresh &&
git diff-files --quiet --ignore-submodules &&
Try that with the original read-tree line and t4151 should pass.
Ah, you should change "Applying 6" with "Applying \"6\"" in t4151-am-abort.sh
too.
Olivier.
From: Stephan Beyer <hidden> Date: 2016-06-15 22:45:00
Hi,
Olivier Marin wrote:
quoted
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....
Are you talking about your seq-proto-dev3 branch?
Right, and your suggested changes are right, too, and I've incorporated
them yesterday (with an --allow-dirty option) but I hadn't commited them...
(Hence, not pushed.)
quoted
Now, because t4151 does not pass, I am wondering what's the best thing
I could do...
Well, that was solved...
The problem was that the additional "HEAD" (that made t4151 work), resulted
in untracked files in some test cases of sequencer and rebase-i. Those made
merges fail, because these merges would overwrite these files. So the
merges failed, and the test cases failed.
I've solved this with the trick that the "HEAD" argument is only added if
--allow-dirty is set (and git-am uses --allow-dirty of course).
This is perhaps not the cleanest way but seemed to be far more better
than forcing overwrites on merges (checkouts, etc.).
Ah, you should change "Applying 6" with "Applying \"6\"" in t4151-am-abort.sh
too.
I btw wondered if the quotes are useful in original am.
Well, I've just sent a patch adding a colon (instead of quotes). Let's
see ;)
Regards,
Stephan
--
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F