{"thread":{"id":"22955","subject":"git-rebase -i prunes commits with empty commit-message","startedAt":"2010-03-08T20:07:41Z","lastAt":"2010-03-11T13:46:15Z","messageCount":6,"participants":["Erik Faye-Lund","Michael Haggerty","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"136406","messageId":"40aa078e1003081207u20046916yda5a62d44ce7a401@mail.gmail.com","threadId":"22955","inReplyTo":null,"subject":"git-rebase -i prunes commits with empty commit-message","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-03-08T20:07:41Z","receivedAt":"2010-03-08T20:07:41Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"I'm in the process of converting an SVN repo to Git, and in the\nprocess I found one quite disturbing feature of\ngit-rebase--interactive.sh: It discards commits with empty commit\nmessages!\n\nHere's a recepie for reproducing the issue:\n--->8---\ngit init\ngit commit -m \"dummy\" --allow-empty\ngit commit -m \"dummy\" --allow-empty\ngit commit -m \"dummy\" --allow-empty\ngit filter-branch -f --msg-filter 'sed -e \"s/dummy//\"'\ngit rebase -i HEAD~2\n--->8---\n\nThe editor window will show \"noop\", and exiting the editor goes ahead\nand deletes all but the initial commit.\n\nThis gets even weirder if it's a mixture of empty and non-empty\ncommits; the commit-identifiers gets appended, together with an\nangle-bracket ('>'), to the previous line.\n\nI'm guessing that this is unintended behavior. This was observed on git 1.7.0.1.\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"136507","messageId":"4B979AEF.5010201@alum.mit.edu","threadId":"22955","inReplyTo":"40aa078e1003081207u20046916yda5a62d44ce7a401@mail.gmail.com","subject":"Re: git-rebase -i prunes commits with empty commit-message","fromName":"Michael Haggerty","fromEmail":"mhagger@alum.mit.edu","sentAt":"2010-03-10T13:13:19Z","receivedAt":"2010-03-10T13:13:19Z","isPatch":false,"sender":{"key":"mhagger@alum.mit.edu","avatar":"https://avatars.githubusercontent.com/u/119718?v=4"},"body":"Erik Faye-Lund wrote:\n> I'm in the process of converting an SVN repo to Git, and in the\n> process I found one quite disturbing feature of\n> git-rebase--interactive.sh: It discards commits with empty commit\n> messages!\n> \n> Here's a recepie for reproducing the issue:\n> --->8---\n> git init\n> git commit -m \"dummy\" --allow-empty\n> git commit -m \"dummy\" --allow-empty\n> git commit -m \"dummy\" --allow-empty\n> git filter-branch -f --msg-filter 'sed -e \"s/dummy//\"'\n> git rebase -i HEAD~2\n> --->8---\n\nDoes git really claim to handle commits with empty commit messages?\nThat you have to use git-filter-branch to create the test case suggests\nthat the answer is \"no\", but I don't know. (git-commit, for example,\nrefuses to create a commit with an empty message.)\n\nIf indeed git requires commit messages to be non-empty, then the fault\nhere seemingly lies with git-filter-branch for allowing commit messages\nto be completely deleted.\n\nMichael\n"},{"id":"136510","messageId":"40aa078e1003100534j189eef5kd60855f80e9dd626@mail.gmail.com","threadId":"22955","inReplyTo":"4B979AEF.5010201@alum.mit.edu","subject":"Re: git-rebase -i prunes commits with empty commit-message","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-03-10T13:34:39Z","receivedAt":"2010-03-10T13:34:39Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Wed, Mar 10, 2010 at 2:13 PM, Michael Haggerty wrote:\n> Erik Faye-Lund wrote:\n>> I'm in the process of converting an SVN repo to Git, and in the\n>> process I found one quite disturbing feature of\n>> git-rebase--interactive.sh: It discards commits with empty commit\n>> messages!\n>>\n>> Here's a recepie for reproducing the issue:\n>> --->8---\n>> git init\n>> git commit -m \"dummy\" --allow-empty\n>> git commit -m \"dummy\" --allow-empty\n>> git commit -m \"dummy\" --allow-empty\n>> git filter-branch -f --msg-filter 'sed -e \"s/dummy//\"'\n>> git rebase -i HEAD~2\n>> --->8---\n>\n> Does git really claim to handle commits with empty commit messages?\n> That you have to use git-filter-branch to create the test case suggests\n> that the answer is \"no\", but I don't know.  (git-commit, for example,\n> refuses to create a commit with an empty message.)\n\nIf git didn't, I'd expect it to be impossible to create them. This was\njust a minimal example on how to reproduce it, and it's a silly\nuse-case. I think my original way of getting into the state was a tad\nmore legitimate:\n1) I had an SVN-repo with empty commit-messages\n2) I imported that SVN-repo into git through git-svn, and git-svn\nappended it's meta-data to the otherwise empty commit-message.\n3) I used git-filter-branch to remove the git-svn metadata (as the\ngit-filter-branch man-page suggest)\n\nI don't know what happens when git-svn encounter empty commit-messages\nwith the --no-metadata option enabled. In my case, the decision to\nfully migrate the repo to Git (instead of just using git-svn as a\nnicer svn-frontend) came long after 1) and 2) were done.\n\n> If indeed git requires commit messages to be non-empty, then the fault\n> here seemingly lies with git-filter-branch for allowing commit messages\n> to be completely deleted.\n\nIf there is some decided-upon restriction that commit-messages cannot\nbe empty, then I agree with you.\n\nFrom experiments, it seems that git-commit does not seem to allow\nempty commit-messages. But I can't find this documented. I'm not sure\nwhat git-commit-tree allows, but I think it should deny creating\ncommits with empty messages (possibly unless some option is given) if\nthere should be a restriction, because most scripts use this to\ngenerate commits AFAIK.\n\nBut to be honest, it seems to me like in this precise instance it's\nprobably better to just fix git-rebase--interactive.sh. There's no\ngood reason for it to barf on the commits -- especially since\nnoon-interactive rebase handles them just fine. Unless someone screams\nout loud, I might take a stab at it when I get time.\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"136536","messageId":"7veijsrm19.fsf@alter.siamese.dyndns.org","threadId":"22955","inReplyTo":"4B979AEF.5010201@alum.mit.edu","subject":"Re: git-rebase -i prunes commits with empty commit-message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-03-10T19:53:22Z","receivedAt":"2010-03-10T19:53:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Haggerty writes:\n\n> Does git really claim to handle commits with empty commit messages?\n\nYes, I would say it is a bug in rebase-i if it refuses to deal with\nhistories with such commits. Warning and giving the user a chance to\nadd message _might_ be good, but allowing no way out would be\ninexcusable. Even adding a fake \"(original commit had no message)\"\nas the message and continuing would be better than stopping or\ndropping commits.\n\nThe Porcelain \"git commit\" by default complains if you do not give any\nmessage, because it usually is an end-user mistake to directly use\n\"git commit\" and not writing anything about the resulting commit.\nHowever,\n\n (1) The plumbing allows it because such a policy to forbid commits\n without comments does not belong there, e.g. this would succeed:\n\n $ git commit-tree HEAD^{tree} wrote:\n>\n> But to be honest, it seems to me like in this precise instance it's\n> probably better to just fix git-rebase--interactive.sh. There's no\n> good reason for it to barf on the commits -- especially since\n> noon-interactive rebase handles them just fine. Unless someone screams\n> out loud, I might take a stab at it when I get time.\n>\n\nI think I've found the culprit: git-rev-list doesn't append a\nnewline-separator after commits with empty messages.\ngit-rebase--interactive.sh basically eats git rev-list's output line\nby line, prepending \"pick \".\n\nThis seems to have been introduced in 55246aa \"Don't use \"\"\nfor placeholders and suppress printing of empty user formats.\" by\nMichal Vitecek. It seems he intended to fix a rev-list with\n--pretty=format:\"\" or something like that, but I can't get custom\nformats to work at all with rev-list, even if the documentation says\nit should.\n\nAnyway, the following patch seems to fix the problem for me, but I'm\nnot very confident that it doesn't break whatever Michal was trying to\naddress.\n\n--->8---\ndiff --git a/builtin-rev-list.c b/builtin-rev-list.c\nindex 5679170..b13e1ba 100644\n--- a/builtin-rev-list.c\n+++ b/builtin-rev-list.c\n@@ -134,10 +134,8 @@ static void show_commit(struct commit *commit, void *data)\n if (graph_show_remainder(revs->graph))\n putchar('\\n');\n }\n- } else {\n- if (buf.len)\n- printf(\"%s%c\", buf.buf, info->hdr_termination);\n- }\n+ } else\n+ printf(\"%s%c\", buf.buf, info->hdr_termination);\n strbuf_release(&buf);\n } else {\n if (graph_show_remainder(revs->graph))\n--->8---\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"136601","messageId":"40aa078e1003110546k1bb024d9rbc7ebe24b0112fe2@mail.gmail.com","threadId":"22955","inReplyTo":"40aa078e1003110514n3bdf12ecq6b3a77e0312e742d@mail.gmail.com","subject":"Re: git-rebase -i prunes commits with empty commit-message","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-03-11T13:46:15Z","receivedAt":"2010-03-11T13:46:15Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Thu, Mar 11, 2010 at 2:14 PM, Erik Faye-Lund\n wrote:\n> Anyway, the following patch seems to fix the problem for me, but I'm\n> not very confident that it doesn't break whatever Michal was trying to\n> address.\n>\n\n...or even the test-suite. I should have tested that before posting\nthis, sorry for the noise. Back to the drawing-board.\n\n-- \nErik \"kusma\" Faye-Lund\n"}]}