{"thread":{"id":"44659","subject":"Any interest in 'git merge --continue' as a command","startedAt":"2016-12-09T07:58:04Z","lastAt":"2016-12-15T17:50:34Z","messageCount":26,"participants":["Chris Packham","Jeff King","Jacob Keller","Junio C Hamano","Markus Hitter"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"307329","messageId":"CAFOYHZDs5rBt5+4D_ViMYfV04foq3h_UrsSMA3FfyMzLh9QdwA@mail.gmail.com","threadId":"44659","inReplyTo":null,"subject":"Any interest in 'git merge --continue' as a command","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2016-12-09T07:57:58Z","receivedAt":"2016-12-09T07:58:04Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"I hit this at $dayjob recently.\n\nA developer had got themselves into a confused state when needing to\nresolve a merge conflict.\n\nThey knew about git rebase --continue (and git am and git cherry-pick)\nbut they were unsure how to \"continue\" a merge (it didn't help that\nthe advice saying to use 'git commit' was scrolling off the top of the\nterminal). I know that using 'git commit' has been the standard way to\ncomplete a merge but given other commands have a --continue should\nmerge have it as well?\n"},{"id":"307334","messageId":"20161209091127.sxxczhfslrqsqs3m@sigill.intra.peff.net","threadId":"44659","inReplyTo":"CAFOYHZDs5rBt5+4D_ViMYfV04foq3h_UrsSMA3FfyMzLh9QdwA@mail.gmail.com","subject":"Re: Any interest in 'git merge --continue' as a command","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-09T09:11:27Z","receivedAt":"2016-12-09T09:11:36Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 09, 2016 at 08:57:58PM +1300, Chris Packham wrote:\n\n> I hit this at $dayjob recently.\n> \n> A developer had got themselves into a confused state when needing to\n> resolve a merge conflict.\n> \n> They knew about git rebase --continue (and git am and git cherry-pick)\n> but they were unsure how to \"continue\" a merge (it didn't help that\n> the advice saying to use 'git commit' was scrolling off the top of the\n> terminal). I know that using 'git commit' has been the standard way to\n> complete a merge but given other commands have a --continue should\n> merge have it as well?\n\nIt seems like that would be in line with 35d2fffdb (Provide 'git merge\n--abort' as a synonym to 'git reset --merge', 2010-11-09), whose stated\ngoal was providing consistency with other multi-command operations.\n\nI assume it would _just_ run a vanilla \"git commit\", and not try to do\nany trickery with updating the index (which could be disastrous).\n\n-Peff\n"},{"id":"307337","messageId":"025427FB-D91F-48B4-B031-5AE1C7BAC779@gmail.com","threadId":"44659","inReplyTo":"20161209091127.sxxczhfslrqsqs3m@sigill.intra.peff.net","subject":"Re: Any interest in 'git merge --continue' as a command","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-12-09T10:37:42Z","receivedAt":"2016-12-09T10:37:53Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On December 9, 2016 1:11:27 AM PST, Jeff King wrote:\n>On Fri, Dec 09, 2016 at 08:57:58PM +1300, Chris Packham wrote:\n>\n>> I hit this at $dayjob recently.\n>> \n>> A developer had got themselves into a confused state when needing to\n>> resolve a merge conflict.\n>> \n>> They knew about git rebase --continue (and git am and git\n>cherry-pick)\n>> but they were unsure how to \"continue\" a merge (it didn't help that\n>> the advice saying to use 'git commit' was scrolling off the top of\n>the\n>> terminal). I know that using 'git commit' has been the standard way\n>to\n>> complete a merge but given other commands have a --continue should\n>> merge have it as well?\n>\n>It seems like that would be in line with 35d2fffdb (Provide 'git merge\n>--abort' as a synonym to 'git reset --merge', 2010-11-09), whose stated\n>goal was providing consistency with other multi-command operations.\n>\n>I assume it would _just_ run a vanilla \"git commit\", and not try to do\n>any trickery with updating the index (which could be disastrous).\n>\n>-Peff\n\nThis makes sense to me.\n\nThanks,\nJake\n\n\n"},{"id":"307385","messageId":"xmqqshpwrjyz.fsf@gitster.mtv.corp.google.com","threadId":"44659","inReplyTo":"20161209091127.sxxczhfslrqsqs3m@sigill.intra.peff.net","subject":"Re: Any interest in 'git merge --continue' as a command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-09T19:16:52Z","receivedAt":"2016-12-09T19:16:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n>> They knew about git rebase --continue (and git am and git cherry-pick)\n>> but they were unsure how to \"continue\" a merge (it didn't help that\n>> the advice saying to use 'git commit' was scrolling off the top of the\n>> terminal). I know that using 'git commit' has been the standard way to\n>> complete a merge but given other commands have a --continue should\n>> merge have it as well?\n>\n> It seems like that would be in line with 35d2fffdb (Provide 'git merge\n> --abort' as a synonym to 'git reset --merge', 2010-11-09), whose stated\n> goal was providing consistency with other multi-command operations.\n>\n> I assume it would _just_ run a vanilla \"git commit\", and not try to do\n> any trickery with updating the index (which could be disastrous).\n\nIf we were to have \"merge --continue\", I agree that it would be the\nlogical implementation.\n\nThere is nothing to \"continue\" in a stopped merge where Git asked\nfor help from the user, and because of that, I view the final \"git\ncommit\" as \"concluding the merge\", not \"continuing\". \"continue\"\nmakes quite a lot of sense with rebase and cherry-pick A..B that\nstopped; it concludes the current step and let it continue to\nprocess the remainder. So from that point of view, it somewhat\nfeels strange to call it \"merge --continue\", but it probably is just\nme.\n\n\n\n"},{"id":"307419","messageId":"CAFOYHZAsU_gNb=_K=iMFKFdt60SJ4Wm=Ag5=XMXuQgxNxCqWLA@mail.gmail.com","threadId":"44659","inReplyTo":"xmqqshpwrjyz.fsf@gitster.mtv.corp.google.com","subject":"Re: Any interest in 'git merge --continue' as a command","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2016-12-10T08:49:13Z","receivedAt":"2016-12-10T08:49:21Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Sat, Dec 10, 2016 at 8:16 AM, Junio C Hamano wrote:\n> Jeff King writes:\n>\n>>> They knew about git rebase --continue (and git am and git cherry-pick)\n>>> but they were unsure how to \"continue\" a merge (it didn't help that\n>>> the advice saying to use 'git commit' was scrolling off the top of the\n>>> terminal). I know that using 'git commit' has been the standard way to\n>>> complete a merge but given other commands have a --continue should\n>>> merge have it as well?\n>>\n>> It seems like that would be in line with 35d2fffdb (Provide 'git merge\n>> --abort' as a synonym to 'git reset --merge', 2010-11-09), whose stated\n>> goal was providing consistency with other multi-command operations.\n>>\n>> I assume it would _just_ run a vanilla \"git commit\", and not try to do\n>> any trickery with updating the index (which could be disastrous).\n>\n> If we were to have \"merge --continue\", I agree that it would be the\n> logical implementation.\n>\n> There is nothing to \"continue\" in a stopped merge where Git asked\n> for help from the user, and because of that, I view the final \"git\n> commit\" as \"concluding the merge\", not \"continuing\". \"continue\"\n> makes quite a lot of sense with rebase and cherry-pick A..B that\n> stopped; it concludes the current step and let it continue to\n> process the remainder. So from that point of view, it somewhat\n> feels strange to call it \"merge --continue\", but it probably is just\n> me.\n>\n\nYeah I did think that --continue wasn't quite the right word. git\nmerge --conclude would probably be the most accurate.\n"},{"id":"307422","messageId":"20161210085938.rfbkuwpvyhnhuzhn@sigill.intra.peff.net","threadId":"44659","inReplyTo":"xmqqshpwrjyz.fsf@gitster.mtv.corp.google.com","subject":"Re: Any interest in 'git merge --continue' as a command","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-10T08:59:39Z","receivedAt":"2016-12-10T09:00:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Dec 09, 2016 at 11:16:52AM -0800, Junio C Hamano wrote:\n\n> > It seems like that would be in line with 35d2fffdb (Provide 'git merge\n> > --abort' as a synonym to 'git reset --merge', 2010-11-09), whose stated\n> > goal was providing consistency with other multi-command operations.\n> >\n> > I assume it would _just_ run a vanilla \"git commit\", and not try to do\n> > any trickery with updating the index (which could be disastrous).\n> \n> If we were to have \"merge --continue\", I agree that it would be the\n> logical implementation.\n> \n> There is nothing to \"continue\" in a stopped merge where Git asked\n> for help from the user, and because of that, I view the final \"git\n> commit\" as \"concluding the merge\", not \"continuing\". \"continue\"\n> makes quite a lot of sense with rebase and cherry-pick A..B that\n> stopped; it concludes the current step and let it continue to\n> process the remainder. So from that point of view, it somewhat\n> feels strange to call it \"merge --continue\", but it probably is just\n> me.\n\nNo, I think your reasoning makes sense. But I also think we've already\nchoosen to have \"--continue\" mean \"conclude the current, and continue if\nthere is anything left\" in other contexts (e.g., a single-item\ncherry-pick). It's more vague, but I think it keeps the user's mental\nmodel simpler if we provide a standard set of options for multi-step\ncommands (e.g., always \"--continue/--abort/--skip\", though there are\nsome like merge that omit \"--skip\" if it does not make sense).\n\n-Peff\n"},{"id":"307423","messageId":"20161210090054.w6qhmszcjkatjhm5@sigill.intra.peff.net","threadId":"44659","inReplyTo":"CAFOYHZAsU_gNb=_K=iMFKFdt60SJ4Wm=Ag5=XMXuQgxNxCqWLA@mail.gmail.com","subject":"Re: Any interest in 'git merge --continue' as a command","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-10T09:00:55Z","receivedAt":"2016-12-10T09:01:01Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Dec 10, 2016 at 09:49:13PM +1300, Chris Packham wrote:\n\n> > There is nothing to \"continue\" in a stopped merge where Git asked\n> > for help from the user, and because of that, I view the final \"git\n> > commit\" as \"concluding the merge\", not \"continuing\". \"continue\"\n> > makes quite a lot of sense with rebase and cherry-pick A..B that\n> > stopped; it concludes the current step and let it continue to\n> > process the remainder. So from that point of view, it somewhat\n> > feels strange to call it \"merge --continue\", but it probably is just\n> > me.\n> \n> Yeah I did think that --continue wasn't quite the right word. git\n> merge --conclude would probably be the most accurate.\n\nI'd be against giving it a subtly-different name. It's just going to\nfrustrate people who cannot remember when to use \"--conclude\" and when\nit is \"--continue\". The strength of the proposal, IMHO, is that it\nabstracts the idea of \"go on to the next thing or finish\" across many\ncommands.\n\n-Peff\n"},{"id":"307433","messageId":"CA+P7+xpwzrbuOb_YzyCatvkhHxEAhP1LVWrnP-yDX=-zmL5uhQ@mail.gmail.com","threadId":"44659","inReplyTo":"20161210090054.w6qhmszcjkatjhm5@sigill.intra.peff.net","subject":"Re: Any interest in 'git merge --continue' as a command","fromName":"Jacob Keller","fromEmail":"jacob.keller@gmail.com","sentAt":"2016-12-10T10:58:02Z","receivedAt":"2016-12-10T10:58:28Z","isPatch":false,"sender":{"key":"jacob.keller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/874719?v=4"},"body":"On Sat, Dec 10, 2016 at 1:00 AM, Jeff King wrote:\n> On Sat, Dec 10, 2016 at 09:49:13PM +1300, Chris Packham wrote:\n>\n>> > There is nothing to \"continue\" in a stopped merge where Git asked\n>> > for help from the user, and because of that, I view the final \"git\n>> > commit\" as \"concluding the merge\", not \"continuing\". \"continue\"\n>> > makes quite a lot of sense with rebase and cherry-pick A..B that\n>> > stopped; it concludes the current step and let it continue to\n>> > process the remainder. So from that point of view, it somewhat\n>> > feels strange to call it \"merge --continue\", but it probably is just\n>> > me.\n>>\n>> Yeah I did think that --continue wasn't quite the right word. git\n>> merge --conclude would probably be the most accurate.\n>\n> I'd be against giving it a subtly-different name. It's just going to\n> frustrate people who cannot remember when to use \"--conclude\" and when\n> it is \"--continue\". The strength of the proposal, IMHO, is that it\n> abstracts the idea of \"go on to the next thing or finish\" across many\n> commands.\n>\n> -Peff\n\nAgreed. I think \"continue\" makes sense as the command had to \"stop\"\nthe merge so you could give input, and then you tell git to \"continue\"\nwhich also happens to mean \"finish the merge\" and yes it may not be\n100% accurate, but the point of adding \"git merge --continue\" is that\nit simplifies the mental model between rebase, cherry-pick, and merge,\nall of which stop and ask the user to resolve a conflict before\n\"continue\"ing and finalizing that resolution.\n\nThanks,\nJake\n"},{"id":"307441","messageId":"xmqqoa0jps4d.fsf@gitster.mtv.corp.google.com","threadId":"44659","inReplyTo":"20161210085938.rfbkuwpvyhnhuzhn@sigill.intra.peff.net","subject":"Re: Any interest in 'git merge --continue' as a command","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-10T18:16:02Z","receivedAt":"2016-12-10T18:16:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> No, I think your reasoning makes sense. But I also think we've already\n> choosen to have \"--continue\" mean \"conclude the current, and continue if\n> there is anything left\" in other contexts (e.g., a single-item\n> cherry-pick). It's more vague, but I think it keeps the user's mental\n> model simpler if we provide a standard set of options for multi-step\n> commands (e.g., always \"--continue/--abort/--skip\", though there are\n> some like merge that omit \"--skip\" if it does not make sense).\n\nYup. I know you know me well enough to know that I didn't mean to\nsay \"oh this one needs to be called differently\" ;-) I just felt\nthat \"--continue\" in that context did not sit well.\n"},{"id":"307490","messageId":"20161212083413.7334-1-judge.packham@gmail.com","threadId":"44659","inReplyTo":"CAFOYHZAsU_gNb=_K=iMFKFdt60SJ4Wm=Ag5=XMXuQgxNxCqWLA@mail.gmail.com","subject":"[RFC/PATCH] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2016-12-12T08:34:13Z","receivedAt":"2016-12-12T08:34:28Z","isPatch":true,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Teach 'git merge' the --continue option which allows 'continuing' a\nmerge by completing it. The traditional way of completing a merge after\nresolving conflicts is to use 'git commit'. Now with commands like 'git\nrebase' and 'git cherry-pick' having a '--continue' option adding such\nan option to 'git merge' presents a consistent UI.\n\nSigned-off-by: Chris Packham \n---\nSo here is a quick patch that adds the --continue option. I need to add\nsome tests (suggestions for where to start are welcome).\n\n Documentation/git-merge.txt | 13 ++++++++++++-\n builtin/merge.c | 17 ++++++++++++++++-\n 2 files changed, 28 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex b758d5556..765b0f26e 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -15,6 +15,7 @@ SYNOPSIS\n \t[--[no-]rerere-autoupdate] [-m ] [...]\n 'git merge' HEAD ...\n 'git merge' --abort\n+'git merge' --continue\n \n DESCRIPTION\n -----------\n@@ -61,6 +62,9 @@ reconstruct the original (pre-merge) changes. Therefore:\n discouraged: while possible, it may leave you in a state that is hard to\n back out of in the case of a conflict.\n \n+The fourth syntax (\"`git merge --continue`\") can only be run after the\n+merge has resulted in conflicts. 'git merge --continue' will take the\n+currently staged changes and complete the merge.\n \n OPTIONS\n -------\n@@ -99,6 +103,12 @@ commit or stash your changes before running 'git merge'.\n 'git merge --abort' is equivalent to 'git reset --merge' when\n `MERGE_HEAD` is present.\n \n+--continue::\n+\tTake the currently staged changes and complete the merge.\n++\n+'git merge --continue' is equivalent to 'git commit' when\n+`MERGE_HEAD` is present.\n+\n ...::\n \tCommits, usually other branch heads, to merge into our branch.\n \tSpecifying more than one commit will create a merge with\n@@ -277,7 +287,8 @@ After seeing a conflict, you can do two things:\n \n * Resolve the conflicts. Git will mark the conflicts in\n the working tree. Edit the files into shape and\n- 'git add' them to the index. Use 'git commit' to seal the deal.\n+ 'git add' them to the index. Use 'git merge --continue' to seal the\n+ deal.\n \n You can work through the conflict with a number of tools:\n \ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex b65eeaa87..1ce18cbbe 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -65,6 +65,7 @@ static int option_renormalize;\n static int verbosity;\n static int allow_rerere_auto;\n static int abort_current_merge;\n+static int continue_current_merge;\n static int allow_unrelated_histories;\n static int show_progress = -1;\n static int default_to_upstream = 1;\n@@ -223,6 +224,8 @@ static struct option builtin_merge_options[] = {\n \tOPT__VERBOSITY(&verbosity),\n \tOPT_BOOL(0, \"abort\", &abort_current_merge,\n \t\tN_(\"abort the current in-progress merge\")),\n+\tOPT_BOOL(0, \"continue\", &continue_current_merge,\n+\t\tN_(\"continue the current in-progress merge\")),\n \tOPT_BOOL(0, \"allow-unrelated-histories\", &allow_unrelated_histories,\n \t\t N_(\"allow merging unrelated histories\")),\n \tOPT_SET_INT(0, \"progress\", &show_progress, N_(\"force progress reporting\"), 1),\n@@ -739,7 +742,7 @@ static void abort_commit(struct commit_list *remoteheads, const char *err_msg)\n \tif (err_msg)\n \t\terror(\"%s\", err_msg);\n \tfprintf(stderr,\n-\t\t_(\"Not committing merge; use 'git commit' to complete the merge.\\n\"));\n+\t\t_(\"Not committing merge; use 'git merge --continue' to complete the merge.\\n\"));\n \twrite_merge_state(remoteheads);\n \texit(1);\n }\n@@ -1166,6 +1169,18 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\tgoto done;\n \t}\n \n+\tif (continue_current_merge) {\n+\t\tint nargc = 1;\n+\t\tconst char *nargv[] = {\"commit\", NULL};\n+\n+\t\tif (!file_exists(git_path_merge_head()))\n+\t\t\tdie(_(\"There is no merge in progress (MERGE_HEAD missing).\"));\n+\n+\t\t/* Invoke 'git commit' */\n+\t\tret = cmd_commit(nargc, nargv, prefix);\n+\t\tgoto done;\n+\t}\n+\n \tif (read_cache_unmerged())\n \t\tdie_resolve_conflict(\"merge\");\n \n-- \n2.11.0\n\n"},{"id":"307492","messageId":"b814932a-b395-2b27-979f-cd170ba363ee@jump-ing.de","threadId":"44659","inReplyTo":"20161212083413.7334-1-judge.packham@gmail.com","subject":"Re: [RFC/PATCH] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Markus Hitter","fromEmail":"mah@jump-ing.de","sentAt":"2016-12-12T09:02:29Z","receivedAt":"2016-12-12T09:02:38Z","isPatch":true,"sender":{"key":"mah@jump-ing.de","avatar":"https://avatars.githubusercontent.com/u/318581?v=4"},"body":"Am 12.12.2016 um 09:34 schrieb Chris Packham:\n> Teach 'git merge' the --continue option which allows 'continuing' a\n> merge by completing it. The traditional way of completing a merge after\n> resolving conflicts is to use 'git commit'. Now with commands like 'git\n> rebase' and 'git cherry-pick' having a '--continue' option adding such\n> an option to 'git merge' presents a consistent UI.\n\nLike.\n\nWhile Junio is entirely right that this is redundant, the inner workings of Git are just voodoo for a (guessed) 95% of users out there, so a consistent UI is important.\n\n> DESCRIPTION\n> -----------\n> @@ -61,6 +62,9 @@ reconstruct the original (pre-merge) changes. Therefore:\n> discouraged: while possible, it may leave you in a state that is hard to\n> back out of in the case of a conflict.\n> \n> +The fourth syntax (\"`git merge --continue`\") can only be run after the\n> +merge has resulted in conflicts. 'git merge --continue' will take the\n> +currently staged changes and complete the merge.\n\nI think this should mention the equivalence to 'git commit'.\n\n\nMarkus\n\n-- \n- - - - - - - - - - - - - - - - - - -\nDipl. Ing. (FH) Markus Hitter\nhttp://www.jump-ing.de/\n"},{"id":"307495","messageId":"20161212094009.wfejbdullac37oi3@sigill.intra.peff.net","threadId":"44659","inReplyTo":"20161212083413.7334-1-judge.packham@gmail.com","subject":"Re: [RFC/PATCH] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-12T09:40:09Z","receivedAt":"2016-12-12T09:40:20Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Dec 12, 2016 at 09:34:13PM +1300, Chris Packham wrote:\n\n> Teach 'git merge' the --continue option which allows 'continuing' a\n> merge by completing it. The traditional way of completing a merge after\n> resolving conflicts is to use 'git commit'. Now with commands like 'git\n> rebase' and 'git cherry-pick' having a '--continue' option adding such\n> an option to 'git merge' presents a consistent UI.\n> \n> Signed-off-by: Chris Packham \n> ---\n> So here is a quick patch that adds the --continue option. I need to add\n> some tests (suggestions for where to start are welcome).\n\nI'm not sure if there's much to test besides concluding a successful\nmerge, and possibly some error cases where --continue should complain.\nProbably that could go at the end of t7600.\n\n> @@ -1166,6 +1169,18 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n> \t\tgoto done;\n> \t}\n> \n> +\tif (continue_current_merge) {\n> +\t\tint nargc = 1;\n> +\t\tconst char *nargv[] = {\"commit\", NULL};\n> +\n> +\t\tif (!file_exists(git_path_merge_head()))\n> +\t\t\tdie(_(\"There is no merge in progress (MERGE_HEAD missing).\"));\n> +\n> +\t\t/* Invoke 'git commit' */\n> +\t\tret = cmd_commit(nargc, nargv, prefix);\n> +\t\tgoto done;\n> +\t}\n> +\n\nI know this block is just adapted from the \"--abort\" one above, but\nshould both of these complain when other arguments are given? I can't\nimagine what the user might mean with \"git merge --no-commit\n--continue\", but probably it should be an error. :)\n\n-Peff\n"},{"id":"307578","messageId":"CAFOYHZCEOXxFCih9E00kf1A7Y_QKe2GCuCB6w8_DJVRevNN9CQ@mail.gmail.com","threadId":"44659","inReplyTo":"b814932a-b395-2b27-979f-cd170ba363ee@jump-ing.de","subject":"Re: [RFC/PATCH] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2016-12-13T08:33:23Z","receivedAt":"2016-12-13T08:33:29Z","isPatch":true,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Mon, Dec 12, 2016 at 10:02 PM, Markus Hitter wrote:\n> Am 12.12.2016 um 09:34 schrieb Chris Packham:\n>> Teach 'git merge' the --continue option which allows 'continuing' a\n>> merge by completing it. The traditional way of completing a merge after\n>> resolving conflicts is to use 'git commit'. Now with commands like 'git\n>> rebase' and 'git cherry-pick' having a '--continue' option adding such\n>> an option to 'git merge' presents a consistent UI.\n>\n> Like.\n>\n> While Junio is entirely right that this is redundant, the inner workings of Git are just voodoo for a (guessed) 95% of users out there, so a consistent UI is important.\n>\n>> DESCRIPTION\n>> -----------\n>> @@ -61,6 +62,9 @@ reconstruct the original (pre-merge) changes. Therefore:\n>> discouraged: while possible, it may leave you in a state that is hard to\n>> back out of in the case of a conflict.\n>>\n>> +The fourth syntax (\"`git merge --continue`\") can only be run after the\n>> +merge has resulted in conflicts. 'git merge --continue' will take the\n>> +currently staged changes and complete the merge.\n>\n> I think this should mention the equivalence to 'git commit'.\n>\n\nIt is mentioned in the OPTIONS section where the --continue option is\ndocumented. I could move it here but the OPTIONS section is where the\n--abort synonym also has a reference to git reset --merge.\n\n>\n> Markus\n>\n> --\n> - - - - - - - - - - - - - - - - - - -\n> Dipl. Ing. (FH) Markus Hitter\n> http://www.jump-ing.de/\n"},{"id":"307580","messageId":"20161213084859.13426-1-judge.packham@gmail.com","threadId":"44659","inReplyTo":"20161212083413.7334-1-judge.packham@gmail.com","subject":"[PATCHv2 1/2] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2016-12-13T08:48:58Z","receivedAt":"2016-12-13T08:49:33Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Teach 'git merge' the --continue option which allows 'continuing' a\nmerge by completing it. The traditional way of completing a merge after\nresolving conflicts is to use 'git commit'. Now with commands like 'git\nrebase' and 'git cherry-pick' having a '--continue' option adding such\nan option to 'git merge' presents a consistent UI.\n\nSigned-off-by: Chris Packham \n---\n\nNotes:\n Changes in v2:\n - add --continue to builtin_merge_usage\n - verify that no other arguments are present when --continue is used.\n - add basic test\n\n Documentation/git-merge.txt | 13 ++++++++++++-\n builtin/merge.c | 22 +++++++++++++++++++++-\n t/t7600-merge.sh | 8 ++++++++\n 3 files changed, 41 insertions(+), 2 deletions(-)\n\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex b758d5556..765b0f26e 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -15,6 +15,7 @@ SYNOPSIS\n \t[--[no-]rerere-autoupdate] [-m ] [...]\n 'git merge' HEAD ...\n 'git merge' --abort\n+'git merge' --continue\n \n DESCRIPTION\n -----------\n@@ -61,6 +62,9 @@ reconstruct the original (pre-merge) changes. Therefore:\n discouraged: while possible, it may leave you in a state that is hard to\n back out of in the case of a conflict.\n \n+The fourth syntax (\"`git merge --continue`\") can only be run after the\n+merge has resulted in conflicts. 'git merge --continue' will take the\n+currently staged changes and complete the merge.\n \n OPTIONS\n -------\n@@ -99,6 +103,12 @@ commit or stash your changes before running 'git merge'.\n 'git merge --abort' is equivalent to 'git reset --merge' when\n `MERGE_HEAD` is present.\n \n+--continue::\n+\tTake the currently staged changes and complete the merge.\n++\n+'git merge --continue' is equivalent to 'git commit' when\n+`MERGE_HEAD` is present.\n+\n ...::\n \tCommits, usually other branch heads, to merge into our branch.\n \tSpecifying more than one commit will create a merge with\n@@ -277,7 +287,8 @@ After seeing a conflict, you can do two things:\n \n * Resolve the conflicts. Git will mark the conflicts in\n the working tree. Edit the files into shape and\n- 'git add' them to the index. Use 'git commit' to seal the deal.\n+ 'git add' them to the index. Use 'git merge --continue' to seal the\n+ deal.\n \n You can work through the conflict with a number of tools:\n \ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex b65eeaa87..379685223 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -46,6 +46,7 @@ static const char * const builtin_merge_usage[] = {\n \tN_(\"git merge [] [...]\"),\n \tN_(\"git merge [] HEAD \"),\n \tN_(\"git merge --abort\"),\n+\tN_(\"git merge --continue\"),\n \tNULL\n };\n \n@@ -65,6 +66,7 @@ static int option_renormalize;\n static int verbosity;\n static int allow_rerere_auto;\n static int abort_current_merge;\n+static int continue_current_merge;\n static int allow_unrelated_histories;\n static int show_progress = -1;\n static int default_to_upstream = 1;\n@@ -223,6 +225,8 @@ static struct option builtin_merge_options[] = {\n \tOPT__VERBOSITY(&verbosity),\n \tOPT_BOOL(0, \"abort\", &abort_current_merge,\n \t\tN_(\"abort the current in-progress merge\")),\n+\tOPT_BOOL(0, \"continue\", &continue_current_merge,\n+\t\tN_(\"continue the current in-progress merge\")),\n \tOPT_BOOL(0, \"allow-unrelated-histories\", &allow_unrelated_histories,\n \t\t N_(\"allow merging unrelated histories\")),\n \tOPT_SET_INT(0, \"progress\", &show_progress, N_(\"force progress reporting\"), 1),\n@@ -739,7 +743,7 @@ static void abort_commit(struct commit_list *remoteheads, const char *err_msg)\n \tif (err_msg)\n \t\terror(\"%s\", err_msg);\n \tfprintf(stderr,\n-\t\t_(\"Not committing merge; use 'git commit' to complete the merge.\\n\"));\n+\t\t_(\"Not committing merge; use 'git merge --continue' to complete the merge.\\n\"));\n \twrite_merge_state(remoteheads);\n \texit(1);\n }\n@@ -1166,6 +1170,22 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\tgoto done;\n \t}\n \n+\tif (continue_current_merge) {\n+\t\tint nargc = 1;\n+\t\tconst char *nargv[] = {\"commit\", NULL};\n+\n+\t\tif (argc)\n+\t\t\tusage_msg_opt(\"--continue expects no arguments\",\n+\t\t\t builtin_merge_usage, builtin_merge_options);\n+\n+\t\tif (!file_exists(git_path_merge_head()))\n+\t\t\tdie(_(\"There is no merge in progress (MERGE_HEAD missing).\"));\n+\n+\t\t/* Invoke 'git commit' */\n+\t\tret = cmd_commit(nargc, nargv, prefix);\n+\t\tgoto done;\n+\t}\n+\n \tif (read_cache_unmerged())\n \t\tdie_resolve_conflict(\"merge\");\n \ndiff --git a/t/t7600-merge.sh b/t/t7600-merge.sh\nindex 85248a14b..44b34ef3a 100755\n--- a/t/t7600-merge.sh\n+++ b/t/t7600-merge.sh\n@@ -154,6 +154,7 @@ test_expect_success 'test option parsing' '\n \ttest_must_fail git merge -s foobar c1 &&\n \ttest_must_fail git merge -s=foobar c1 &&\n \ttest_must_fail git merge -m &&\n+\ttest_must_fail git merge --continue foobar &&\n \ttest_must_fail git merge\n '\n \n@@ -763,4 +764,11 @@ test_expect_success 'merge nothing into void' '\n \t)\n '\n \n+test_expect_success 'merge can be completed with --continue' '\n+\tgit reset --hard c0 &&\n+\tgit merge --no-ff --no-commit c1 &&\n+\tgit merge --continue &&\n+\tverify_parents $c0 $c1\n+'\n+\n test_done\n-- \n2.11.0.24.ge6920cf\n\n"},{"id":"307581","messageId":"20161213084859.13426-2-judge.packham@gmail.com","threadId":"44659","inReplyTo":"20161213084859.13426-1-judge.packham@gmail.com","subject":"[PATCHv2 2/2] completion: add --continue option for merge","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2016-12-13T08:48:59Z","receivedAt":"2016-12-13T08:49:36Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Add 'git merge --continue' option when completing.\n\nSigned-off-by: Chris Packham \n---\n\nNotes:\n Changes in v2:\n - new.\n\n contrib/completion/git-completion.bash | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 21016bf8d..1f97ffae1 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -1552,7 +1552,7 @@ _git_merge ()\n \tcase \"$cur\" in\n \t--*)\n \t\t__gitcomp \"$__git_merge_options\n-\t\t\t--rerere-autoupdate --no-rerere-autoupdate --abort\"\n+\t\t\t--rerere-autoupdate --no-rerere-autoupdate --abort --continue\"\n \t\treturn\n \tesac\n \t__gitcomp_nl \"$(__git_refs)\"\n-- \n2.11.0.24.ge6920cf\n\n"},{"id":"307591","messageId":"20161213115931.tz7ce3z2meaxydbh@sigill.intra.peff.net","threadId":"44659","inReplyTo":"20161213084859.13426-1-judge.packham@gmail.com","subject":"Re: [PATCHv2 1/2] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-13T11:59:31Z","receivedAt":"2016-12-13T11:59:42Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Dec 13, 2016 at 09:48:58PM +1300, Chris Packham wrote:\n\n> +\tif (continue_current_merge) {\n> +\t\tint nargc = 1;\n> +\t\tconst char *nargv[] = {\"commit\", NULL};\n> +\n> +\t\tif (argc)\n> +\t\t\tusage_msg_opt(\"--continue expects no arguments\",\n> +\t\t\t builtin_merge_usage, builtin_merge_options);\n\nThis checks that we don't have:\n\n git merge --continue foobar\n\nbut still allows:\n\n git merge --continue --some-option\n\nbecause parse_options() decrements argc.\n\nIt would be insane to check individually which options might have been\nset. But I wonder if we could do something like:\n\n int orig_argc = argc;\n ...\n argc = parse_options(argc, argv, ...);\n\n if (continue_current_merge) {\n\tif (orig_argc != 1) /* maybe 2, to account for argv[0] ? */\n\t\tusage_msg_opt(\"--continue expects no arguments\", ...);\n }\n\nThat gets trickier if there ever is an option that's OK to use with\n--continue. We might want to forward along \"--quiet\", for example. On\nthe other hand, we silently ignore it now, so maybe it is better to\ncomplain and then let --quiet get added later if somebody cares.\n\nWhatever we do here, I think \"--abort\" should get the same treatment\n(probably as a separate patch).\n\n> diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh\n> index 85248a14b..44b34ef3a 100755\n> --- a/t/t7600-merge.sh\n> +++ b/t/t7600-merge.sh\n> @@ -154,6 +154,7 @@ test_expect_success 'test option parsing' '\n> \ttest_must_fail git merge -s foobar c1 &&\n> \ttest_must_fail git merge -s=foobar c1 &&\n> \ttest_must_fail git merge -m &&\n> +\ttest_must_fail git merge --continue foobar &&\n> \ttest_must_fail git merge\n> '\n\nYour tests look good, though obviously if you check for options above,\nthat should be covered in this test.\n\n-Peff\n"},{"id":"307642","messageId":"xmqq60mn671x.fsf@gitster.mtv.corp.google.com","threadId":"44659","inReplyTo":"20161213084859.13426-1-judge.packham@gmail.com","subject":"Re: [PATCHv2 1/2] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-13T18:02:50Z","receivedAt":"2016-12-13T18:03:08Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Packham writes:\n\n> +'git merge' --continue\n> \n> DESCRIPTION\n> -----------\n> @@ -61,6 +62,9 @@ reconstruct the original (pre-merge) changes. Therefore:\n> discouraged: while possible, it may leave you in a state that is hard to\n> back out of in the case of a conflict.\n> \n> +The fourth syntax (\"`git merge --continue`\") can only be run after the\n> +merge has resulted in conflicts.\n\nOK. I can see that the code refuses if there is no MERGE_HEAD, so\n\"can only be run\" is ensured correctly.\n\n> 'git merge --continue' will take the\n> +currently staged changes and complete the merge.\n\nFor Git-savvy folks, this may be sufficient to tell that they are\nexpected to resolve conflicts in the working tree and register the\nresolusion by doing \"git add\" before running \"git merge --continue\",\nbut I wonder if that is clear enough for new readers.\n\nThe same comment applies to the option description below. I suspect\nthat it is better to remove the last sentence above, leaving \"4th\none can be run only with MERGE_HEAD\" here, and enhance the\nexplanation in the option description (see below).\n\n> OPTIONS\n> -------\n> @@ -99,6 +103,12 @@ commit or stash your changes before running 'git merge'.\n> 'git merge --abort' is equivalent to 'git reset --merge' when\n> `MERGE_HEAD` is present.\n> \n> +--continue::\n> +\tTake the currently staged changes and complete the merge.\n> ++\n> +'git merge --continue' is equivalent to 'git commit' when\n> +`MERGE_HEAD` is present.\n> +\n\nThese two sentences are even more technical and unfriendly to new\nreaders, I am afraid. How about giving a hint by referring to an\nexisting section, like this?\n\n --continue::\n After a \"git merge\" stops due to conflicts you can conclude\n the merge by running \"git merge --continue\" (see \"How to\n resolve conflicts\" section below).\n\n> @@ -277,7 +287,8 @@ After seeing a conflict, you can do two things:\n> \n> * Resolve the conflicts. Git will mark the conflicts in\n> the working tree. Edit the files into shape and\n> - 'git add' them to the index. Use 'git commit' to seal the deal.\n> + 'git add' them to the index. Use 'git merge --continue' to seal the\n> + deal.\n\nWhy do we want to make it harder to discover \"git commit\" here?\nI would understand:\n\n\t... Use 'git commit' to conclude (you can also say 'git\n\tmerge --continue').\n\nthough. After all, we are merely introducing a synonym for those\nwho want to type more. There is no plan to deprecate the use of\n'git commit', which is a perfectly reasonable way to conclude an\ninterrupted merge, that has worked well for us for the past 10 years\nand still works.\n\n> @@ -65,6 +66,7 @@ static int option_renormalize;\n> static int verbosity;\n> static int allow_rerere_auto;\n> static int abort_current_merge;\n> +static int continue_current_merge;\n> static int allow_unrelated_histories;\n> static int show_progress = -1;\n> static int default_to_upstream = 1;\n> @@ -223,6 +225,8 @@ static struct option builtin_merge_options[] = {\n> \tOPT__VERBOSITY(&verbosity),\n> \tOPT_BOOL(0, \"abort\", &abort_current_merge,\n> \t\tN_(\"abort the current in-progress merge\")),\n> +\tOPT_BOOL(0, \"continue\", &continue_current_merge,\n> +\t\tN_(\"continue the current in-progress merge\")),\n> \tOPT_BOOL(0, \"allow-unrelated-histories\", &allow_unrelated_histories,\n> \t\t N_(\"allow merging unrelated histories\")),\n> \tOPT_SET_INT(0, \"progress\", &show_progress, N_(\"force progress reporting\"), 1),\n> @@ -739,7 +743,7 @@ static void abort_commit(struct commit_list *remoteheads, const char *err_msg)\n> \tif (err_msg)\n> \t\terror(\"%s\", err_msg);\n> \tfprintf(stderr,\n> -\t\t_(\"Not committing merge; use 'git commit' to complete the merge.\\n\"));\n> +\t\t_(\"Not committing merge; use 'git merge --continue' to complete the merge.\\n\"));\n\nLikewise. I do not see a need to change this one at all.\n\n> @@ -1166,6 +1170,22 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n> \t\tgoto done;\n> \t}\n> \n> +\tif (continue_current_merge) {\n> +\t\tint nargc = 1;\n> +\t\tconst char *nargv[] = {\"commit\", NULL};\n> +\n> +\t\tif (argc)\n> +\t\t\tusage_msg_opt(\"--continue expects no arguments\",\n> +\t\t\t builtin_merge_usage, builtin_merge_options);\n\nPeff already commented on \"what about other options?\", and I think\nhis \"check the number of args before parse-options ran to ensure\nthat the '--abort' or '--continue' was the only thing\" is probably\na workable hack.\n\nThe \"right\" way to fix it would be way too involved to be worth for\njust this single change (and also fixing \"--abort\"). Just thinking\naloud:\n\n * Update parse-options API to:\n\n - extend \"struct option\" with one field that holds what \"command\n modes\" the option the \"struct option\" describes is incompatible\n with.\n\n - make parse_options() to keep track of the set of command modes\n that are compatible with the options seen so far, and complain\n if an option that is not compatible with the command mode is\n given.\n\n * Use the above facility to update \"git merge\" so that --abort and\n --continue becomes OPT_CMDMODE.\n\nThen, the updated parse_options() would:\n\n - start by making the \"incompatible command modes\" an empty set.\n\n - while it processes each option on the command line:\n\n - if it is not an OPTION_CMDMODE, add the set of command modes\n that are incompatible with the option to the \"incompatible\n command modes\".\n\n - if it is an OPTION_CMDMODE and we already saw another\n OPTION_CMDMODE, error out (we already do this).\n\n - after all options are read, check the final command mode and see\n if that is in \"incompatible command modes\".\n\nYou can mark almost all options \"git merge\" takes except a selected\nfew like \"--quiet\" as incompatible with \"--abort\" and \"--continue\"\nand let parse_options() catch incompatible options. Of course you\nstill need to check argc for non-option here.\n\n"},{"id":"307745","messageId":"20161214083757.26412-2-judge.packham@gmail.com","threadId":"44659","inReplyTo":"20161214083757.26412-1-judge.packham@gmail.com","subject":"[PATCH 2/3] completion: add --continue option for merge","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2016-12-14T08:37:56Z","receivedAt":"2016-12-14T08:38:44Z","isPatch":true,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Add 'git merge --continue' option when completing.\n\nSigned-off-by: Chris Packham \n---\nChanges in v2:\n- new\nChanges in v3:\n- none\n\n contrib/completion/git-completion.bash | 2 +-\n 1 file changed, 1 insertion(+), 1 deletion(-)\n\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 21016bf8d..1f97ffae1 100644\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -1552,7 +1552,7 @@ _git_merge ()\n \tcase \"$cur\" in\n \t--*)\n \t\t__gitcomp \"$__git_merge_options\n-\t\t\t--rerere-autoupdate --no-rerere-autoupdate --abort\"\n+\t\t\t--rerere-autoupdate --no-rerere-autoupdate --abort --continue\"\n \t\treturn\n \tesac\n \t__gitcomp_nl \"$(__git_refs)\"\n-- \n2.11.0.24.ge6920cf\n\n"},{"id":"307746","messageId":"20161214083757.26412-3-judge.packham@gmail.com","threadId":"44659","inReplyTo":"20161214083757.26412-1-judge.packham@gmail.com","subject":"[PATCH 3/3] merge: Ensure '--abort' option takes no arguments","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2016-12-14T08:37:57Z","receivedAt":"2016-12-14T08:38:48Z","isPatch":true,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Like '--continue', the '--abort' option doesn't make any sense with\nother options or arguments to 'git merge' so ensure that none are\npresent.\n\nSigned-off-by: Chris Packham \n---\nChanges in v3:\n- new\n\n builtin/merge.c | 4 ++++\n t/t7600-merge.sh | 2 ++\n 2 files changed, 6 insertions(+)\n\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex 836ec281b..668aaffb8 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -1163,6 +1163,10 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\tint nargc = 2;\n \t\tconst char *nargv[] = {\"reset\", \"--merge\", NULL};\n \n+\t\tif (orig_argc != 2)\n+\t\t\tusage_msg_opt(\"--abort expects no arguments\",\n+\t\t\t builtin_merge_usage, builtin_merge_options);\n+\n \t\tif (!file_exists(git_path_merge_head()))\n \t\t\tdie(_(\"There is no merge to abort (MERGE_HEAD missing).\"));\n \ndiff --git a/t/t7600-merge.sh b/t/t7600-merge.sh\nindex 682139c4e..2ebda509a 100755\n--- a/t/t7600-merge.sh\n+++ b/t/t7600-merge.sh\n@@ -154,6 +154,8 @@ test_expect_success 'test option parsing' '\n \ttest_must_fail git merge -s foobar c1 &&\n \ttest_must_fail git merge -s=foobar c1 &&\n \ttest_must_fail git merge -m &&\n+\ttest_must_fail git merge --abort foobar &&\n+\ttest_must_fail git merge --abort --quiet &&\n \ttest_must_fail git merge --continue foobar &&\n \ttest_must_fail git merge --continue --quiet &&\n \ttest_must_fail git merge\n-- \n2.11.0.24.ge6920cf\n\n"},{"id":"307747","messageId":"20161214083757.26412-1-judge.packham@gmail.com","threadId":"44659","inReplyTo":"20161213084859.13426-1-judge.packham@gmail.com","subject":"[PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2016-12-14T08:37:55Z","receivedAt":"2016-12-14T08:38:53Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"Teach 'git merge' the --continue option which allows 'continuing' a\nmerge by completing it. The traditional way of completing a merge after\nresolving conflicts is to use 'git commit'. Now with commands like 'git\nrebase' and 'git cherry-pick' having a '--continue' option adding such\nan option to 'git merge' presents a consistent UI.\n\nSigned-off-by: Chris Packham \n---\nChanges in v2:\n- add --continue to builtin_merge_usage\n- verify that no other arguments are present when --continue is used.\n- add basic test\nChanges in v3:\n- check for other options in addtion to arguments, add test for this case\n- re-instate references to 'git commit' that were removed in v2\n- re-work documentation\n\n Documentation/git-merge.txt | 8 ++++++++\n builtin/merge.c | 21 +++++++++++++++++++++\n t/t7600-merge.sh | 9 +++++++++\n 3 files changed, 38 insertions(+)\n\ndiff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt\nindex b758d5556..ca3c27b88 100644\n--- a/Documentation/git-merge.txt\n+++ b/Documentation/git-merge.txt\n@@ -15,6 +15,7 @@ SYNOPSIS\n \t[--[no-]rerere-autoupdate] [-m ] [...]\n 'git merge' HEAD ...\n 'git merge' --abort\n+'git merge' --continue\n \n DESCRIPTION\n -----------\n@@ -61,6 +62,8 @@ reconstruct the original (pre-merge) changes. Therefore:\n discouraged: while possible, it may leave you in a state that is hard to\n back out of in the case of a conflict.\n \n+The fourth syntax (\"`git merge --continue`\") can only be run after the\n+merge has resulted in conflicts.\n \n OPTIONS\n -------\n@@ -99,6 +102,11 @@ commit or stash your changes before running 'git merge'.\n 'git merge --abort' is equivalent to 'git reset --merge' when\n `MERGE_HEAD` is present.\n \n+--continue::\n+\tAfter a 'git merge' stops due to conflicts you can conclude the\n+\tmerge by running 'git merge --continue' (see \"HOW TO RESOLVE\n+\tCONFLICTS\" section below).\n+\n ...::\n \tCommits, usually other branch heads, to merge into our branch.\n \tSpecifying more than one commit will create a merge with\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex b65eeaa87..836ec281b 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -46,6 +46,7 @@ static const char * const builtin_merge_usage[] = {\n \tN_(\"git merge [] [...]\"),\n \tN_(\"git merge [] HEAD \"),\n \tN_(\"git merge --abort\"),\n+\tN_(\"git merge --continue\"),\n \tNULL\n };\n \n@@ -65,6 +66,7 @@ static int option_renormalize;\n static int verbosity;\n static int allow_rerere_auto;\n static int abort_current_merge;\n+static int continue_current_merge;\n static int allow_unrelated_histories;\n static int show_progress = -1;\n static int default_to_upstream = 1;\n@@ -223,6 +225,8 @@ static struct option builtin_merge_options[] = {\n \tOPT__VERBOSITY(&verbosity),\n \tOPT_BOOL(0, \"abort\", &abort_current_merge,\n \t\tN_(\"abort the current in-progress merge\")),\n+\tOPT_BOOL(0, \"continue\", &continue_current_merge,\n+\t\tN_(\"continue the current in-progress merge\")),\n \tOPT_BOOL(0, \"allow-unrelated-histories\", &allow_unrelated_histories,\n \t\t N_(\"allow merging unrelated histories\")),\n \tOPT_SET_INT(0, \"progress\", &show_progress, N_(\"force progress reporting\"), 1),\n@@ -1125,6 +1129,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \tconst char *best_strategy = NULL, *wt_strategy = NULL;\n \tstruct commit_list *remoteheads, *p;\n \tvoid *branch_to_free;\n+\tint orig_argc = argc;\n \n \tif (argc == 2 && !strcmp(argv[1], \"-h\"))\n \t\tusage_with_options(builtin_merge_usage, builtin_merge_options);\n@@ -1166,6 +1171,22 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\tgoto done;\n \t}\n \n+\tif (continue_current_merge) {\n+\t\tint nargc = 1;\n+\t\tconst char *nargv[] = {\"commit\", NULL};\n+\n+\t\tif (orig_argc != 2)\n+\t\t\tusage_msg_opt(\"--continue expects no arguments\",\n+\t\t\t builtin_merge_usage, builtin_merge_options);\n+\n+\t\tif (!file_exists(git_path_merge_head()))\n+\t\t\tdie(_(\"There is no merge in progress (MERGE_HEAD missing).\"));\n+\n+\t\t/* Invoke 'git commit' */\n+\t\tret = cmd_commit(nargc, nargv, prefix);\n+\t\tgoto done;\n+\t}\n+\n \tif (read_cache_unmerged())\n \t\tdie_resolve_conflict(\"merge\");\n \ndiff --git a/t/t7600-merge.sh b/t/t7600-merge.sh\nindex 85248a14b..682139c4e 100755\n--- a/t/t7600-merge.sh\n+++ b/t/t7600-merge.sh\n@@ -154,6 +154,8 @@ test_expect_success 'test option parsing' '\n \ttest_must_fail git merge -s foobar c1 &&\n \ttest_must_fail git merge -s=foobar c1 &&\n \ttest_must_fail git merge -m &&\n+\ttest_must_fail git merge --continue foobar &&\n+\ttest_must_fail git merge --continue --quiet &&\n \ttest_must_fail git merge\n '\n \n@@ -763,4 +765,11 @@ test_expect_success 'merge nothing into void' '\n \t)\n '\n \n+test_expect_success 'merge can be completed with --continue' '\n+\tgit reset --hard c0 &&\n+\tgit merge --no-ff --no-commit c1 &&\n+\tgit merge --continue &&\n+\tverify_parents $c0 $c1\n+'\n+\n test_done\n-- \n2.11.0.24.ge6920cf\n\n"},{"id":"307782","messageId":"20161214152039.swtll7xrmcdwz7bc@sigill.intra.peff.net","threadId":"44659","inReplyTo":"20161214083757.26412-1-judge.packham@gmail.com","subject":"Re: [PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-14T15:20:39Z","receivedAt":"2016-12-14T15:21:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Dec 14, 2016 at 09:37:55PM +1300, Chris Packham wrote:\n\n> +\tif (continue_current_merge) {\n> +\t\tint nargc = 1;\n> +\t\tconst char *nargv[] = {\"commit\", NULL};\n> +\n> +\t\tif (orig_argc != 2)\n> +\t\t\tusage_msg_opt(\"--continue expects no arguments\",\n> +\t\t\t builtin_merge_usage, builtin_merge_options);\n\nThis message should probably be inside a _() for translation.\n\nI noticed when running it that the output looks funny:\n\n $ git merge --continue foo\n --continue expects no arguments\n\n usage: [...]\n\nI was going to suggest adding something like \"fatal:\" here, but I\nactually think it should be the responsibility of usage_msg_opt().\nLooking at its other callers, they would all benefit. I posted a\npatch:\n\n http://public-inbox.org/git/20161214151009.4wdzjb44f6aki5ug@sigill.intra.peff.net/\n\nI also wondered what it would look like to support \"--quiet\" on top of\nthis. I don't care that much about it in particular, but I just want to\nmake sure we're not painting ourselves into a corner.\n\nHere's what I came up with;\n\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex 668aaffb8..b13523ce9 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -1160,10 +1160,16 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\tshow_progress = 0;\n \n \tif (abort_current_merge) {\n-\t\tint nargc = 2;\n-\t\tconst char *nargv[] = {\"reset\", \"--merge\", NULL};\n+\t\tint acceptable_arguments = 2; /* argv[0] plus --abort */\n+\t\tstruct argv_array nargv = ARGV_ARRAY_INIT;\n \n-\t\tif (orig_argc != 2)\n+\t\targv_array_pushl(&nargv, \"reset\", \"--merge\", NULL);\n+\t\tif (verbosity < 0) {\n+\t\t\tacceptable_arguments++;\n+\t\t\targv_array_push(&nargv, \"--quiet\");\n+\t\t}\n+\n+\t\tif (orig_argc != acceptable_arguments)\n \t\t\tusage_msg_opt(\"--abort expects no arguments\",\n \t\t\t builtin_merge_usage, builtin_merge_options);\n \n@@ -1171,15 +1177,22 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\t\tdie(_(\"There is no merge to abort (MERGE_HEAD missing).\"));\n \n \t\t/* Invoke 'git reset --merge' */\n-\t\tret = cmd_reset(nargc, nargv, prefix);\n+\t\tret = cmd_reset(nargv.argc, nargv.argv, prefix);\n+\t\targv_array_clear(&nargv);\n \t\tgoto done;\n \t}\n \n \tif (continue_current_merge) {\n-\t\tint nargc = 1;\n-\t\tconst char *nargv[] = {\"commit\", NULL};\n+\t\tint acceptable_arguments = 2; /* argv[0] plus --abort */\n+\t\tstruct argv_array nargv = ARGV_ARRAY_INIT;\n+\n+\t\targv_array_push(&nargv, \"commit\");\n+\t\tif (verbosity < 0) {\n+\t\t\tacceptable_arguments++;\n+\t\t\targv_array_push(&nargv, \"--quiet\");\n+\t\t}\n \n-\t\tif (orig_argc != 2)\n+\t\tif (orig_argc != acceptable_arguments)\n \t\t\tusage_msg_opt(\"--continue expects no arguments\",\n \t\t\t builtin_merge_usage, builtin_merge_options);\n \n@@ -1187,7 +1200,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\t\tdie(_(\"There is no merge in progress (MERGE_HEAD missing).\"));\n \n \t\t/* Invoke 'git commit' */\n-\t\tret = cmd_commit(nargc, nargv, prefix);\n+\t\tret = cmd_commit(nargv.argc, nargv.argv, prefix);\n+\t\targv_array_clear(&nargv);\n \t\tgoto done;\n \t}\n \n\nSo not too bad (and you could probably refactor it to avoid some of the\nduplication). Though it does get some obscure cases wrong, like:\n\n git merge --continue --verbose --quiet\n\nI dunno. Maybe I am leading you down a rabbit hole, and we should just\nlive with silently ignoring useless options. I looked at what\ncherry-pick does for this case, and its verify_opt_compatible is\nsomewhat scary from a maintenance standpoint. It's a whitelist, not a\nblacklist, so it's easy to forget options (and it looks like \"git\ncherry-pick --abort -Sfoo\" is missed, for example).\n\n-Peff\n"},{"id":"307786","messageId":"xmqq4m26zbph.fsf@gitster.mtv.corp.google.com","threadId":"44659","inReplyTo":"20161214152039.swtll7xrmcdwz7bc@sigill.intra.peff.net","subject":"Re: [PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-14T17:01:46Z","receivedAt":"2016-12-14T17:07:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> So not too bad (and you could probably refactor it to avoid some of the\n> duplication). Though it does get some obscure cases wrong, like:\n>\n> git merge --continue --verbose --quiet\n>\n> I dunno. Maybe I am leading you down a rabbit hole, and we should just\n> live with silently ignoring useless options.\n\nI think you need to handle this in parse-options API if you really\nwanted to do this correctly. \n\n may serve as a\nreasonable outline for building one.\n"},{"id":"307795","messageId":"xmqqk2b2xu81.fsf@gitster.mtv.corp.google.com","threadId":"44659","inReplyTo":"20161214083757.26412-1-judge.packham@gmail.com","subject":"Re: [PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-14T18:04:46Z","receivedAt":"2016-12-14T18:05:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"The last one 3/3 is a nice touch that makes sure that we do not\nforget what we discovered during the discussion. Very much\nappreciated.\n\nWill queue. Thanks.\n"},{"id":"307831","messageId":"CAFOYHZD_mFMvggq4pedjGCz332i1-VcRKxu30iMzURfB3Mu8Vg@mail.gmail.com","threadId":"44659","inReplyTo":"xmqqk2b2xu81.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Chris Packham","fromEmail":"judge.packham@gmail.com","sentAt":"2016-12-15T07:29:21Z","receivedAt":"2016-12-15T07:29:27Z","isPatch":false,"sender":{"key":"judge.packham@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155667?v=4"},"body":"On Thu, Dec 15, 2016 at 7:04 AM, Junio C Hamano wrote:\n> The last one 3/3 is a nice touch that makes sure that we do not\n> forget what we discovered during the discussion. Very much\n> appreciated.\n>\n> Will queue. Thanks.\n\nDid you want me to send a v4 to mark the strings for translation or\nwill you apply a fixup your end?\n"},{"id":"307849","messageId":"xmqqd1gtw0vi.fsf@gitster.mtv.corp.google.com","threadId":"44659","inReplyTo":"CAFOYHZD_mFMvggq4pedjGCz332i1-VcRKxu30iMzURfB3Mu8Vg@mail.gmail.com","subject":"Re: [PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-12-15T17:36:17Z","receivedAt":"2016-12-15T17:37:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Chris Packham writes:\n\n> On Thu, Dec 15, 2016 at 7:04 AM, Junio C Hamano wrote:\n>> The last one 3/3 is a nice touch that makes sure that we do not\n>> forget what we discovered during the discussion. Very much\n>> appreciated.\n>>\n>> Will queue. Thanks.\n>\n> Did you want me to send a v4 to mark the strings for translation or\n> will you apply a fixup your end?\n\nI didn't follow the _() discussion (was there any?)\n\nI do not think lack of _() is a show-stopper and my preference is to\nkeep what I queued that does not have _(), and receive a separate\nfollow-up patch that changes \"msg\" to _(\"msg\") and does nothing\nelse.\n\nThanks.\n"},{"id":"307851","messageId":"20161215174345.tekbcthjqqcpohaf@sigill.intra.peff.net","threadId":"44659","inReplyTo":"xmqqd1gtw0vi.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCHv3 1/3] merge: Add '--continue' option as a synonym for 'git commit'","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-12-15T17:43:46Z","receivedAt":"2016-12-15T17:50:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Dec 15, 2016 at 09:36:17AM -0800, Junio C Hamano wrote:\n\n> > Did you want me to send a v4 to mark the strings for translation or\n> > will you apply a fixup your end?\n> \n> I didn't follow the _() discussion (was there any?)\n\nI think the discussion was just \"we should do that\".\n\n> I do not think lack of _() is a show-stopper and my preference is to\n> keep what I queued that does not have _(), and receive a separate\n> follow-up patch that changes \"msg\" to _(\"msg\") and does nothing\n> else.\n\nHere's a patch.\n\n-- >8 --\nSubject: merge: mark usage error strings for translation\n\nThe nearby error messages are already marked for\ntranslation, but these new ones aren't.\n\nSigned-off-by: Jeff King \n---\n builtin/merge.c | 4 ++--\n 1 file changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex 668aaffb8..599d25c4c 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -1164,7 +1164,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\tconst char *nargv[] = {\"reset\", \"--merge\", NULL};\n \n \t\tif (orig_argc != 2)\n-\t\t\tusage_msg_opt(\"--abort expects no arguments\",\n+\t\t\tusage_msg_opt(_(\"--abort expects no arguments\"),\n \t\t\t builtin_merge_usage, builtin_merge_options);\n \n \t\tif (!file_exists(git_path_merge_head()))\n@@ -1180,7 +1180,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)\n \t\tconst char *nargv[] = {\"commit\", NULL};\n \n \t\tif (orig_argc != 2)\n-\t\t\tusage_msg_opt(\"--continue expects no arguments\",\n+\t\t\tusage_msg_opt(_(\"--continue expects no arguments\"),\n \t\t\t builtin_merge_usage, builtin_merge_options);\n \n \t\tif (!file_exists(git_path_merge_head()))\n-- \n2.11.0.348.g960a0b554\n\n"}]}