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) # we created merge conflict $ <MERGE_STASH is removed together with MERGE_HEAD> -- Jakub Narebski Poland -- 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
