{"thread":{"id":"27458","subject":"Merge made by recursive?","startedAt":"2011-05-25T17:28:07Z","lastAt":"2011-05-25T22:46:26Z","messageCount":10,"participants":["Shawn Ligocki","Ramkumar Ramachandra","Jakub Narebski","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"168689","messageId":"loom.20110525T192418-887@post.gmane.org","threadId":"27458","inReplyTo":null,"subject":"Merge made by recursive?","fromName":"Shawn Ligocki","fromEmail":"sligocki@gmail.com","sentAt":"2011-05-25T17:28:07Z","receivedAt":"2011-05-25T17:28:07Z","isPatch":false,"sender":{"key":"sligocki@gmail.com","avatar":null},"body":"Is this intentionally bad grammar? Every time I see it, I cringe a little. What \ndoes it even mean? That it merged incrementally through each subsequent revision?\n\nCheers,\n-Shawn\n"},{"id":"168691","messageId":"BANLkTikRW+k38sHcokL=FsNmLRNF0+E--w@mail.gmail.com","threadId":"27458","inReplyTo":"loom.20110525T192418-887@post.gmane.org","subject":"Re: Merge made by recursive?","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2011-05-25T17:42:28Z","receivedAt":"2011-05-25T17:42:28Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi Shawn,\n\nShawn Ligocki writes:\n> Is this intentionally bad grammar? Every time I see it, I cringe a little. What\n> does it even mean? That it merged incrementally through each subsequent revision?\n\nI suppose it's yet another quirk I've got used to -- \"recursive\"\nrefers to the merge strategy that was used; see git-merge(1). We can\ndefinitely make the Porcelain say something nicer like `merged\nsuccessfully using \"recursive\" merge strategy`.\n\nPatches are welcome: see Documentation/SubmittingPatches :)\n\n-- Ram\n"},{"id":"168695","messageId":"m339k2zmh8.fsf@localhost.localdomain","threadId":"27458","inReplyTo":"loom.20110525T192418-887@post.gmane.org","subject":"Re: Merge made by recursive?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2011-05-25T18:04:05Z","receivedAt":"2011-05-25T18:04:05Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Shawn Ligocki <sligocki@gmail.com> writes:\n\n> Is this intentionally bad grammar? Every time I see it, I cringe a little. What \n> does it even mean? That it merged incrementally through each subsequent revision?\n\n\"Merge made by recursive\" means \"Merge made by 'recursive' merge strategy\",\nwhere 'recursive' part refers to the fact that in case of criss-cross\nmerge\n\n        /--*---B1---M1---*---#  <-- foo\n       /        \\  /\n   ---B           x\n       \\         / \\\n        \\--*---B2---M2---*---#  <-- bar\n\n(you are trying to merge 'bar' into 'foo') when we have more than one\nmerge base, the strategy first creates synthetic merge for B1 and B2\n\n\n                    M1---*---#  <-- foo\n                   /\n                  X\n                   \\\n                    M2---*---#  <-- bar\n\nand uses this X as a merge base for further merging.  Or something\nlike that.\n\nSee \"Merge strategies\" section in git-merge(1) documentation.\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"168704","messageId":"7vvcwy37de.fsf@alter.siamese.dyndns.org","threadId":"27458","inReplyTo":"loom.20110525T192418-887@post.gmane.org","subject":"Re: Merge made by recursive?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-25T19:30:53Z","receivedAt":"2011-05-25T19:30:53Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Ligocki <sligocki@gmail.com> writes:\n\n> Is this intentionally bad grammar? Every time I see it, I cringe a little.\n\nI think so.  An earlier version of \"git merge\" used to say something like:\n\n    Committed merge ..., made by resolve.\n\nback in Sept 2005, so it is not so recent development. If we change it\nnow, scripts in thousands of existing users hands might cringe instead,\nthough.\n\n builtin/merge.c               |    2 +-\n t/t7602-merge-octopus-many.sh |    6 +++---\n 2 files changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex 5a2a1eb..8bc453d 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -902,7 +902,7 @@ static int finish_automerge(struct commit_list *common,\n \tstrbuf_addch(&merge_msg, '\\n');\n \trun_prepare_commit_msg();\n \tcommit_tree(merge_msg.buf, result_tree, parents, result_commit, NULL);\n-\tstrbuf_addf(&buf, \"Merge made by %s.\", wt_strategy);\n+\tstrbuf_addf(&buf, \"Merge made by the '%s' strategy.\", wt_strategy);\n \tfinish(result_commit, buf.buf);\n \tstrbuf_release(&buf);\n \tdrop_save();\ndiff --git a/t/t7602-merge-octopus-many.sh b/t/t7602-merge-octopus-many.sh\nindex 0a46795..61f36ba 100755\n--- a/t/t7602-merge-octopus-many.sh\n+++ b/t/t7602-merge-octopus-many.sh\n@@ -53,7 +53,7 @@ cat >expected <<\\EOF\n Trying simple merge with c2\n Trying simple merge with c3\n Trying simple merge with c4\n-Merge made by octopus.\n+Merge made by the 'octopus' strategy.\n  c2.c |    1 +\n  c3.c |    1 +\n  c4.c |    1 +\n@@ -72,7 +72,7 @@ test_expect_success 'merge output uses pretty names' '\n cat >expected <<\\EOF\n Already up-to-date with c4\n Trying simple merge with c5\n-Merge made by octopus.\n+Merge made by the 'octopus' strategy.\n  c5.c |    1 +\n  1 files changed, 1 insertions(+), 0 deletions(-)\n  create mode 100644 c5.c\n@@ -86,7 +86,7 @@ test_expect_success 'merge up-to-date output uses pretty names' '\n cat >expected <<\\EOF\n Fast-forwarding to: c1\n Trying simple merge with c2\n-Merge made by octopus.\n+Merge made by the 'octopus' strategy.\n  c1.c |    1 +\n  c2.c |    1 +\n  2 files changed, 2 insertions(+), 0 deletions(-)\n"},{"id":"168709","messageId":"20110525195032.GC27260@sigill.intra.peff.net","threadId":"27458","inReplyTo":"7vvcwy37de.fsf@alter.siamese.dyndns.org","subject":"Re: Merge made by recursive?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-25T19:50:32Z","receivedAt":"2011-05-25T19:50:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 25, 2011 at 12:30:53PM -0700, Junio C Hamano wrote:\n\n> I think so.  An earlier version of \"git merge\" used to say something like:\n> \n>     Committed merge ..., made by resolve.\n> \n> back in Sept 2005, so it is not so recent development. If we change it\n> now, scripts in thousands of existing users hands might cringe instead,\n> though.\n\nI was going to say \"those scripts are stupid and broken for parsing\nstderr\", but:\n\n  1. We actually write this (and many other diagnostic messages) to\n     stdout, not stderr. That seems weird and unusual.\n\n  2. The message ends up in the reflog.\n\nAlso, most of the rest of the merge output has been gettext-ized, but\nnot this message. If we are going to declare it not parseable, should we\nalso be internationalizing it?\n\n-Peff\n"},{"id":"168714","messageId":"7vei3m3571.fsf@alter.siamese.dyndns.org","threadId":"27458","inReplyTo":"20110525195032.GC27260@sigill.intra.peff.net","subject":"Re: Merge made by recursive?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-25T20:17:54Z","receivedAt":"2011-05-25T20:17:54Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> Also, most of the rest of the merge output has been gettext-ized, but\n> not this message. If we are going to declare it not parseable, should we\n> also be internationalizing it?\n\nHeh, great minds think alike. I was wondering about that while I took a\nbrief walk after sending it out.\n"},{"id":"168716","messageId":"7vzkma1p95.fsf@alter.siamese.dyndns.org","threadId":"27458","inReplyTo":"7vei3m3571.fsf@alter.siamese.dyndns.org","subject":"Re: Merge made by recursive?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-25T20:47:34Z","receivedAt":"2011-05-25T20:47:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jeff King <peff@peff.net> writes:\n>\n>> Also, most of the rest of the merge output has been gettext-ized, but\n>> not this message. If we are going to declare it not parseable, should we\n>> also be internationalizing it?\n>\n> Heh, great minds think alike. I was wondering about that while I took a\n> brief walk after sending it out.\n\nI am reluctant to do this (including the rewording of the end-user facing\nmessage) until we decide what to do with the reflog. Right now, I think no\ntool looks at the reflog, but contaminating the reflog with translatable\nmessages mean that we will never be able to support \"3 merges ago\" just\nlike we support \"the previous branch\".\n\nEither we split the messages into two, one translatable and given to the\nend user and the other untranslatable and sent to the reflog, or find a\nplace in reflog entry where we can hide machine readable and stable\nrepresentation of what happened and store both the end-user facing message\nand the machine readable one separately. In the longer term I would prefer\nthe latter.\n\n-- >8 --\nSubject: [PATCH] merge: mark the final \"Merge made by...\" message for l10n\n\nThe final \"Merge made by ... strategy\" message is an end-user facing\nmessage and can be localized.  And mark the test that depends on the exact\nwording with test_i18ncmp.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n builtin/merge.c               |    2 +-\n t/t7602-merge-octopus-many.sh |    6 +++---\n 2 files changed, 4 insertions(+), 4 deletions(-)\n\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex 8bc453d..4083b9b 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -902,7 +902,7 @@ static int finish_automerge(struct commit_list *common,\n \tstrbuf_addch(&merge_msg, '\\n');\n \trun_prepare_commit_msg();\n \tcommit_tree(merge_msg.buf, result_tree, parents, result_commit, NULL);\n-\tstrbuf_addf(&buf, \"Merge made by the '%s' strategy.\", wt_strategy);\n+\tstrbuf_addf(&buf, _(\"Merge made by the '%s' strategy.\"), wt_strategy);\n \tfinish(result_commit, buf.buf);\n \tstrbuf_release(&buf);\n \tdrop_save();\ndiff --git a/t/t7602-merge-octopus-many.sh b/t/t7602-merge-octopus-many.sh\nindex 61f36ba..3f893de 100755\n--- a/t/t7602-merge-octopus-many.sh\n+++ b/t/t7602-merge-octopus-many.sh\n@@ -66,7 +66,7 @@ EOF\n test_expect_success 'merge output uses pretty names' '\n \tgit reset --hard c1 &&\n \tgit merge c2 c3 c4 >actual &&\n-\ttest_cmp actual expected\n+\ttest_i18ncmp actual expected\n '\n \n cat >expected <<\\EOF\n@@ -80,7 +80,7 @@ EOF\n \n test_expect_success 'merge up-to-date output uses pretty names' '\n \tgit merge c4 c5 >actual &&\n-\ttest_cmp actual expected\n+\ttest_i18ncmp actual expected\n '\n \n cat >expected <<\\EOF\n@@ -97,7 +97,7 @@ EOF\n test_expect_success 'merge fast-forward output uses pretty names' '\n \tgit reset --hard c0 &&\n \tgit merge c1 c2 >actual &&\n-\ttest_cmp actual expected\n+\ttest_i18ncmp actual expected\n '\n \n test_done\n-- \n1.7.5.2.483.gc61ca\n"},{"id":"168718","messageId":"20110525210254.GA29716@sigill.intra.peff.net","threadId":"27458","inReplyTo":"7vzkma1p95.fsf@alter.siamese.dyndns.org","subject":"Re: Merge made by recursive?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-25T21:02:54Z","receivedAt":"2011-05-25T21:02:54Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 25, 2011 at 01:47:34PM -0700, Junio C Hamano wrote:\n\n> I am reluctant to do this (including the rewording of the end-user facing\n> message) until we decide what to do with the reflog. Right now, I think no\n> tool looks at the reflog, but contaminating the reflog with translatable\n> messages mean that we will never be able to support \"3 merges ago\" just\n> like we support \"the previous branch\".\n\nThe reflog messages look like:\n\n  merge $branch: Merge made by recursive.\n\nSo it seems to me that we could localize everything after the colon and\nstill do \"3 merges ago\". The only thing you would be losing is a\nmachine-readable description of which strategy was used. In practice,\nI'm not sure how much it matters.\n\nBut for others, like:\n\n  checkout: moving from $old to $new\n\na localized version loses useful information.\n\n> Either we split the messages into two, one translatable and given to the\n> end user and the other untranslatable and sent to the reflog,\n\nThat seems like the safe choice for now, as it still opens the\npossibility of localizing reflogs later if people care to do so.  Being\na native English speaker, I have no clue how much people actually care\nabout localized reflog entries.\n\n> place in reflog entry where we can hide machine readable and stable\n> representation of what happened and store both the end-user facing message\n> and the machine readable one separately. In the longer term I would prefer\n> the latter.\n\nIf we assume that reflog entries are machine-readable (or at least\n_some_ of them that are generated by a few well-known git programs), you\ncould always translate on the fly while displaying them.\n\nThat solves the storage question, and it allows two people with\ndifferent language preferences to both read the same reflog. And the\nimplementation probably wouldn't be too hard, since we'd only have to\nmatch a few well-known strings, and we could display anything we didn't\nmatch as it appears in the reflog.\n\n-Peff\n"},{"id":"168720","messageId":"20110525212510.GA14214@sigill.intra.peff.net","threadId":"27458","inReplyTo":"20110525210254.GA29716@sigill.intra.peff.net","subject":"Re: Merge made by recursive?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-25T21:25:10Z","receivedAt":"2011-05-25T21:25:10Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 25, 2011 at 05:02:54PM -0400, Jeff King wrote:\n\n> On Wed, May 25, 2011 at 01:47:34PM -0700, Junio C Hamano wrote:\n> \n> > I am reluctant to do this (including the rewording of the end-user facing\n> > message) until we decide what to do with the reflog. Right now, I think no\n> > tool looks at the reflog, but contaminating the reflog with translatable\n> > messages mean that we will never be able to support \"3 merges ago\" just\n> > like we support \"the previous branch\".\n> \n> The reflog messages look like:\n> \n>   merge $branch: Merge made by recursive.\n\nWhile peeking in my reflog, I noticed some very confusing entries, which\nthis patch addresses.\n\n-- >8 --\nSubject: [PATCH] reset: give more verbose reflog messages\n\nThe reset command creates its reflog entry from argv.\nHowever, it does so after having run parse_options, which\nmeans the only thing left in argv is any non-option\narguments. Thus you would end up with confusing reflog\nentries like:\n\n  $ git reset --hard HEAD^\n  $ git reset --soft HEAD@{1}\n  $ git log -2 -g --oneline\n  8e46cad HEAD@{0}: HEAD@{1}: updating HEAD\n  1eb9486 HEAD@{1}: HEAD^: updating HEAD\n\nThis patch sets up the reflog before argv is munged, so you\nget the command name and any other options, like:\n\n  8e46cad HEAD@{0}: reset --soft HEAD@{1}: updating HEAD\n  1eb9486 HEAD@{1}: reset --hard HEAD^: updating HEAD\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\nI am not sure if this was the original intent of the code or not; I had\nto update a test vector which codified it. Any options like \"--hard\" or\n\"--soft\" are actually superfluous to the ref update (not to mention\nsomething like \"-q\"). So another option would be to just take what's\nleft after parsing options and putting \"reset\" in front of it, like:\n\n  8e46cad HEAD@{0}: reset: HEAD^: updating HEAD\n\nwhich is a little more readable. Though if we are going to change it, I\nthink my preference would actually be:\n\n  8e46cad HEAD@{0}: reset: moving to HEAD^\n\nwhich reads better. The \"updating HEAD\" is just pointless. Of course\nwe're updating HEAD; we're in the HEAD reflog and we're running reset!\n\nHowever, if GIT_REFLOG_ACTION is already set (by a script calling us),\nthen we won't say \"reset\". So for example, I have entries in my reflog\nlike:\n\n  944af8c HEAD@{311}: rebase -i (squash): updating HEAD\n\nSo maybe it makes sense to leave those ones as-is, and adjust only the\ncase where GIT_REFLOG_ACTION is unset.\n\n builtin/reset.c        |    5 +++--\n t/t1412-reflog-loop.sh |    8 ++++----\n 2 files changed, 7 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin/reset.c b/builtin/reset.c\nindex 98bca04..77103fb 100644\n--- a/builtin/reset.c\n+++ b/builtin/reset.c\n@@ -259,11 +259,12 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \n \tgit_config(git_default_config, NULL);\n \n-\targc = parse_options(argc, argv, prefix, options, git_reset_usage,\n-\t\t\t\t\t\tPARSE_OPT_KEEP_DASHDASH);\n \treflog_action = args_to_str(argv);\n \tsetenv(\"GIT_REFLOG_ACTION\", reflog_action, 0);\n \n+\targc = parse_options(argc, argv, prefix, options, git_reset_usage,\n+\t\t\t\t\t\tPARSE_OPT_KEEP_DASHDASH);\n+\n \t/*\n \t * Possible arguments are:\n \t *\ndiff --git a/t/t1412-reflog-loop.sh b/t/t1412-reflog-loop.sh\nindex 7f519e5..a92875f 100755\n--- a/t/t1412-reflog-loop.sh\n+++ b/t/t1412-reflog-loop.sh\n@@ -21,10 +21,10 @@ test_expect_success 'setup reflog with alternating commits' '\n \n test_expect_success 'reflog shows all entries' '\n \tcat >expect <<-\\EOF\n-\t\ttopic@{0} two: updating HEAD\n-\t\ttopic@{1} one: updating HEAD\n-\t\ttopic@{2} two: updating HEAD\n-\t\ttopic@{3} one: updating HEAD\n+\t\ttopic@{0} reset two: updating HEAD\n+\t\ttopic@{1} reset one: updating HEAD\n+\t\ttopic@{2} reset two: updating HEAD\n+\t\ttopic@{3} reset one: updating HEAD\n \t\ttopic@{4} branch: Created from HEAD\n \tEOF\n \tgit log -g --format=\"%gd %gs\" topic >actual &&\n-- \n1.7.4.5.34.g0787f\n"},{"id":"168725","messageId":"20110525224626.GA2296@sigill.intra.peff.net","threadId":"27458","inReplyTo":"20110525212510.GA14214@sigill.intra.peff.net","subject":"Re: Merge made by recursive?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-25T22:46:26Z","receivedAt":"2011-05-25T22:46:26Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, May 25, 2011 at 05:25:10PM -0400, Jeff King wrote:\n\n> Though if we are going to change it, I think my preference would\n> actually be:\n> \n>   8e46cad HEAD@{0}: reset: moving to HEAD^\n> \n> which reads better. The \"updating HEAD\" is just pointless. Of course\n> we're updating HEAD; we're in the HEAD reflog and we're running reset!\n\nActually, this gets written also to the branch's reflog, so saying\n\"updating HEAD\" has a little bit of value. Of course, saying \"reset\" is\neven better, since that is the command to update HEAD.\n\n> However, if GIT_REFLOG_ACTION is already set (by a script calling us),\n> then we won't say \"reset\". So for example, I have entries in my reflog\n> like:\n> \n>   944af8c HEAD@{311}: rebase -i (squash): updating HEAD\n> \n> So maybe it makes sense to leave those ones as-is, and adjust only the\n> case where GIT_REFLOG_ACTION is unset.\n\n...and for the reason above, it makes sense to leave this as \"updating\nHEAD\" for the per-branch reflog, since whatever the script put into\nGIT_REFLOG_ACTION may be more clear with that information.\n\nSo here's what I think we should do.\n\n-- >8 --\nSubject: [PATCH] reset: give better reflog messages\n\nThe reset command creates its reflog entry from argv.\nHowever, it does so after having run parse_options, which\nmeans the only thing left in argv is any non-option\narguments. Thus you would end up with confusing reflog\nentries like:\n\n  $ git reset --hard HEAD^\n  $ git reset --soft HEAD@{1}\n  $ git log -2 -g --oneline\n  8e46cad HEAD@{0}: HEAD@{1}: updating HEAD\n  1eb9486 HEAD@{1}: HEAD^: updating HEAD\n\nHowever, we must also consider that some scripts may set\nGIT_REFLOG_ACTION before calling reset, and we need to show\ntheir reflog action (with our text appended). For example:\n\n  rebase -i (squash): updating HEAD\n\nOn top of that, we also set the ORIG_HEAD reflog action\n(even though it doesn't generally exist). In that case, the\nreset argument is somewhat meaningless, as it has nothing to\ndo with what's in ORIG_HEAD.\n\nThis patch changes the reset reflog code to show:\n\n  $GIT_REFLOG_ACTION: updating {HEAD,ORIG_HEAD}\n\nas before, but only if GIT_REFLOG_ACTION is set. Otherwise,\nshow:\n\n   reset: moving to $rev\n\nfor HEAD, and:\n\n   reset: updating ORIG_HEAD\n\nfor ORIG_HEAD (this is still somewhat superfluous, since we\nare in the ORIG_HEAD reflog, obviously, but at least we now\nmention which command was used to update it).\n\nWhile we're at it, we can clean up the code a bit:\n\n  1. Use strbufs to make the message.\n\n  1. Use the \"rev\" parameter instead of showing all options.\n     This makes more sense, since it is the only thing\n     impacting the writing of the ref.\n\nSigned-off-by: Jeff King <peff@peff.net>\n---\n builtin/reset.c        |   49 +++++++++++++++--------------------------------\n t/t1412-reflog-loop.sh |    8 +++---\n 2 files changed, 20 insertions(+), 37 deletions(-)\n\ndiff --git a/builtin/reset.c b/builtin/reset.c\nindex 98bca04..27b3426 100644\n--- a/builtin/reset.c\n+++ b/builtin/reset.c\n@@ -33,25 +33,6 @@ static const char *reset_type_names[] = {\n \tN_(\"mixed\"), N_(\"soft\"), N_(\"hard\"), N_(\"merge\"), N_(\"keep\"), NULL\n };\n \n-static char *args_to_str(const char **argv)\n-{\n-\tchar *buf = NULL;\n-\tunsigned long len, space = 0, nr = 0;\n-\n-\tfor (; *argv; argv++) {\n-\t\tlen = strlen(*argv);\n-\t\tALLOC_GROW(buf, nr + 1 + len, space);\n-\t\tif (nr)\n-\t\t\tbuf[nr++] = ' ';\n-\t\tmemcpy(buf + nr, *argv, len);\n-\t\tnr += len;\n-\t}\n-\tALLOC_GROW(buf, nr + 1, space);\n-\tbuf[nr] = '\\0';\n-\n-\treturn buf;\n-}\n-\n static inline int is_merge(void)\n {\n \treturn !access(git_path(\"MERGE_HEAD\"), F_OK);\n@@ -215,14 +196,18 @@ static int read_from_tree(const char *prefix, const char **argv,\n \treturn update_index_refresh(index_fd, lock, refresh_flags);\n }\n \n-static void prepend_reflog_action(const char *action, char *buf, size_t size)\n+static void set_reflog_message(struct strbuf *sb, const char *action,\n+\t\t\t       const char *rev)\n {\n-\tconst char *sep = \": \";\n \tconst char *rla = getenv(\"GIT_REFLOG_ACTION\");\n-\tif (!rla)\n-\t\trla = sep = \"\";\n-\tif (snprintf(buf, size, \"%s%s%s\", rla, sep, action) >= size)\n-\t\twarning(_(\"Reflog action message too long: %.*s...\"), 50, buf);\n+\n+\tstrbuf_reset(sb);\n+\tif (rla)\n+\t\tstrbuf_addf(sb, \"%s: %s\", rla, action);\n+\telse if (rev)\n+\t\tstrbuf_addf(sb, \"reset: moving to %s\", rev);\n+\telse\n+\t\tstrbuf_addf(sb, \"reset: %s\", action);\n }\n \n static void die_if_unmerged_cache(int reset_type)\n@@ -241,7 +226,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \tunsigned char sha1[20], *orig = NULL, sha1_orig[20],\n \t\t\t\t*old_orig = NULL, sha1_old_orig[20];\n \tstruct commit *commit;\n-\tchar *reflog_action, msg[1024];\n+\tstruct strbuf msg = STRBUF_INIT;\n \tconst struct option options[] = {\n \t\tOPT__QUIET(&quiet, \"be quiet, only report errors\"),\n \t\tOPT_SET_INT(0, \"mixed\", &reset_type,\n@@ -261,8 +246,6 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \n \targc = parse_options(argc, argv, prefix, options, git_reset_usage,\n \t\t\t\t\t\tPARSE_OPT_KEEP_DASHDASH);\n-\treflog_action = args_to_str(argv);\n-\tsetenv(\"GIT_REFLOG_ACTION\", reflog_action, 0);\n \n \t/*\n \t * Possible arguments are:\n@@ -357,13 +340,13 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \t\told_orig = sha1_old_orig;\n \tif (!get_sha1(\"HEAD\", sha1_orig)) {\n \t\torig = sha1_orig;\n-\t\tprepend_reflog_action(\"updating ORIG_HEAD\", msg, sizeof(msg));\n-\t\tupdate_ref(msg, \"ORIG_HEAD\", orig, old_orig, 0, MSG_ON_ERR);\n+\t\tset_reflog_message(&msg, \"updating ORIG_HEAD\", NULL);\n+\t\tupdate_ref(msg.buf, \"ORIG_HEAD\", orig, old_orig, 0, MSG_ON_ERR);\n \t}\n \telse if (old_orig)\n \t\tdelete_ref(\"ORIG_HEAD\", old_orig, 0);\n-\tprepend_reflog_action(\"updating HEAD\", msg, sizeof(msg));\n-\tupdate_ref_status = update_ref(msg, \"HEAD\", sha1, orig, 0, MSG_ON_ERR);\n+\tset_reflog_message(&msg, \"updating HEAD\", rev);\n+\tupdate_ref_status = update_ref(msg.buf, \"HEAD\", sha1, orig, 0, MSG_ON_ERR);\n \n \tswitch (reset_type) {\n \tcase HARD:\n@@ -380,7 +363,7 @@ int cmd_reset(int argc, const char **argv, const char *prefix)\n \n \tremove_branch_state();\n \n-\tfree(reflog_action);\n+\tstrbuf_release(&msg);\n \n \treturn update_ref_status;\n }\ndiff --git a/t/t1412-reflog-loop.sh b/t/t1412-reflog-loop.sh\nindex 7f519e5..647d888 100755\n--- a/t/t1412-reflog-loop.sh\n+++ b/t/t1412-reflog-loop.sh\n@@ -21,10 +21,10 @@ test_expect_success 'setup reflog with alternating commits' '\n \n test_expect_success 'reflog shows all entries' '\n \tcat >expect <<-\\EOF\n-\t\ttopic@{0} two: updating HEAD\n-\t\ttopic@{1} one: updating HEAD\n-\t\ttopic@{2} two: updating HEAD\n-\t\ttopic@{3} one: updating HEAD\n+\t\ttopic@{0} reset: moving to two\n+\t\ttopic@{1} reset: moving to one\n+\t\ttopic@{2} reset: moving to two\n+\t\ttopic@{3} reset: moving to one\n \t\ttopic@{4} branch: Created from HEAD\n \tEOF\n \tgit log -g --format=\"%gd %gs\" topic >actual &&\n-- \n1.7.4.5.34.g0787f\n"}]}