Jakub Narebski [off-list ref] writes:
Junio C Hamano wrote:
quoted
John Tapsell [off-list ref] writes:
quoted
It sounds like we have some sort of plan then. Will Nana's patch be
committed into mainline git? Then we can add the --abort porcelain
I do not know what plan you are talking about, but that's not how the
development works. If something is merged to 'pu', and you have a cool
feature you would want to take advantage of it, you can build your cool
feature on top of that particular topic. If the result looks reasonable
they would cook for a while in 'next' for further polishing and then
finally go to 'mainline'.
I personally did not think "--keep" would need to be be part of a
reasonable "merge --abort" implementation, but I may have missed some
description of a viable design discussed on the list.
My idea was that merge would do the following:
$ <save stash into MERGE_STASH or similar, no reset>
$ <do a merge>
Then we have two possibilities:
# merge failed with conflicts
$ git merge --abort (would unstash MERGE_STASH and delete it)
Here "would unstash" needs to follow something else, namely, make your
work tree free of local changes. How? "reset --hard"?
# we created merge conflict
$ <MERGE_STASH is removed together with MERGE_HEAD>
You mean "created a merge without conflict", right? That part is easy to
guess and understand.
In fact, when you run more than one strategies, something similar to this
already happens internally. The C version may be harder to follow, but
you can check the last scripted version contrib/examples/git-merge.sh and
find two functions, savestate/restorestate pair, that does exactly that.
It way predates --keep patch, by the way.
Junio C Hamano wrote::
Jakub Narebski [off-list ref] writes:
quoted
Junio C Hamano wrote:
quoted
quoted
I personally did not think "--keep" would need to be be part of a
reasonable "merge --abort" implementation, but I may have missed some
description of a viable design discussed on the list.
First, a description of state: here we assume that you have changes to
tracked files in working area that are neither in HEAD, nor in index,
and that you can have changes in index which are neither in HEAD nor
in working area.
If HEAD == index == working area then stashing is not necessary.
quoted
My idea was that merge would do the following:
$ <save stash into MERGE_STASH or similar, no reset>
$ <do a merge>
Then we have two possibilities:
# merge failed with conflicts
$ git merge --abort (would unstash MERGE_STASH and delete it)
Here "would unstash" needs to follow something else, namely, make your
work tree free of local changes. How? "reset --hard"?
Yes. "git merge --abort" would be equivalent to
$ git reset --hard ORIG_HEAD
$ git stash pop --ref=MERGE_STASH
$ rm $GIT_DIR/MERGE_STASH
quoted
# we created merge conflict
$ <MERGE_STASH is removed together with MERGE_HEAD>
You mean "created a merge without conflict", right? That part is easy to
guess and understand.
Yes. I meant here: "created merge _commit_" (not "conflict").
In fact, when you run more than one strategies, something similar to this
already happens internally. The C version may be harder to follow, but
you can check the last scripted version contrib/examples/git-merge.sh and
find two functions, savestate/restorestate pair, that does exactly that.
It way predates --keep patch, by the way.
Well, we have "git reset --merge ORIG_HEAD" which from what I understand
does at least part of "git merge --abort", but I am not sure if it
covers all cases (like dirty index in addition to dirty tree).
--
Jakub Narebski
Poland