Jakub Narebski <jnareb@xxxxxxxxx> writes: > Junio C Hamano wrote: >> John Tapsell <johnflux@xxxxxxxxx> writes: >> >> > 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. -- 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
