{"thread":{"id":"4533","subject":"git-rebase nukes multiline comments","startedAt":"2006-06-16T17:12:51Z","lastAt":"2006-06-19T09:54:44Z","messageCount":9,"participants":["Matthias Hopf","David Kowis","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"21888","messageId":"20060616171251.GA29820@suse.de","threadId":"4533","inReplyTo":null,"subject":"git-rebase nukes multiline comments","fromName":"Matthias Hopf","fromEmail":"mhopf@suse.de","sentAt":"2006-06-16T17:12:51Z","receivedAt":"2006-06-16T17:12:51Z","isPatch":false,"sender":{"key":"mhopf@suse.de","avatar":null},"body":"Hi all,\n\nI'm using git-1.2.4 on SL10.1, in centralized style development (for X.org).\n\nI wanted to commit a set of changes (4 local commits) upstream, so I had\nto do a git-rebase first (in that particular case a git-pull would have\nbeen possible as well, but git-rebase fits the CVS style development\nbetter). After git-fetch, git-rebase origin, and git-push all my changes\nhad only the first line of the changelog comment, the remainder was\nnuked.\n\nTo reproduce:\n\nmkdir /var/tmp/blaup\ncd /var/tmp/blaup\ngit-init-db\necho test > foo\ngit-add foo\ngit-commit      (any comment)\ncd ..\ngit-clone /var/tmp/blaup bla\ncd bla\necho test2 >>foo \ngit-commit foo  (multiline comment)\ncd ../blaup\necho test3 >bar\ngit-add bar\ngit-commit      (any comment)\ncd ../bla\ngit-fetch\ngit-log         (shows multiline comment for 'test2')\ngit-rebase origin\ngit-log         (shows only the first line of the multiline comment!)\n\n\nI doubt this is intended behavior.\n\n\nAlso, while trying to reproduce this with the original upstream\nrepository, I would have had to git-fetch my origin branch (upstream\nmaster), but not to get _all_ new commits, but only up to a certain\nrevspec (the one *before* my own commits).\n\nI tried \"git-fetch <refspec>:\", but this didn't work, neither did\nanything else I tried.  This is clearly beyond my understanding of git,\nso how can this be done?\n\nThanks\n\nMatthias\n\n-- \nMatthias Hopf <mhopf@suse.de>       __        __   __\nMaxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat@mshopf.de\nPhone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de\n"},{"id":"21889","messageId":"4492E8F9.4000106@shlrm.org","threadId":"4533","inReplyTo":"20060616171251.GA29820@suse.de","subject":"Re: git-rebase nukes multiline comments","fromName":"David Kowis","fromEmail":"dkowis@shlrm.org","sentAt":"2006-06-16T17:23:05Z","receivedAt":"2006-06-16T17:23:05Z","isPatch":false,"sender":{"key":"dkowis@shlrm.org","avatar":"https://gravatar.com/avatar/2ebebf02e2dc139286a4ebb90ceda4a07efe0fdb8c3a4c24bc7c1379a1effb4a?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nMatthias Hopf wrote:\n> Hi all,\n> \n> I'm using git-1.2.4 on SL10.1, in centralized style development (for X.org).\n> \n> I wanted to commit a set of changes (4 local commits) upstream, so I had\n> to do a git-rebase first (in that particular case a git-pull would have\n> been possible as well, but git-rebase fits the CVS style development\n> better). After git-fetch, git-rebase origin, and git-push all my changes\n> had only the first line of the changelog comment, the remainder was\n> nuked.\n> \n> To reproduce:\n> \n> mkdir /var/tmp/blaup\n> cd /var/tmp/blaup\n> git-init-db\n> echo test > foo\n> git-add foo\n> git-commit      (any comment)\n> cd ..\n> git-clone /var/tmp/blaup bla\n> cd bla\n> echo test2 >>foo \n> git-commit foo  (multiline comment)\n> cd ../blaup\n> echo test3 >bar\n> git-add bar\n> git-commit      (any comment)\n> cd ../bla\n> git-fetch\n> git-log         (shows multiline comment for 'test2')\n> git-rebase origin\n> git-log         (shows only the first line of the multiline comment!)\n> \n> \n\nI'm new to git, but I tried what you said.\nmy git log:\ncommit c846bea8c61bec7cf0f7688c48abc42577b9ac7f\nAuthor: David Kowis <dkowis@kain.org>\nDate:   Fri Jun 16 12:20:08 2006 -0500\n\n    this is a multi\n\n    line comment\n    with three lines\n\n\nI'm using git 1.4.0. It added a blank line in there...\n\n\nDavid Kowis\n\nISO Team Lead - www.sourcemage.org\nSource Mage GNU/Linux\n\nProgress isn't made by early risers. It's made by lazy men trying to\nfind easier ways to do something.\n  - Robert Heinlein\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2 (MingW32)\n\niQGVAwUBRJLo+cnf+vRw63ObAQomewv+L18ogJHgx3jQPt/B+K84GIAX5SugrSnZ\nASC2jm/sbMdidU1goOepXILw2DBOWKSpuDwTZXE0uDrldMTK4RW/2dDACbGVEQX/\nTer4cclIxNztaAwzXGHqKyOI24c5jQmlzW+yDcnErJZTexDA6xyp4xVZlySJpZev\ntzfj1Di/uYNJ83lcgS9ID64JToZ5sYZjeqy5HjfEpEQR7xHSYoaR94LNjSHMrqU8\nS32ryCMeBSX9SWP8lX7lv6YzIlPGYbOVIsskANVN4GyYVdoMXyXpNtDvziIXrxJj\nFkSCloMq5bzVuykthPer0FQRXiySyM1bWsUt9i7Xf3fF8qzyVpIJghP3GAlwh4Gs\nLRefaUkkVH61FmN+Uw65xxdx99L4ABoZJDpPBhQdOnY+BXbhNGM5p/lAi3iX72Bx\neIMmaWiwxF8XlIaLJFbDVtGA7lwJzneQQUyHHlTZhzu+VXf4ulKPE93NKEuWWqnL\nFD9Tgmu5sFANq5iKSCyocvyAqiWljR8w\n=hQWx\n-----END PGP SIGNATURE-----\n"},{"id":"21892","messageId":"4492F09F.9080906@shlrm.org","threadId":"4533","inReplyTo":"4492E8F9.4000106@shlrm.org","subject":"Re: git-rebase nukes multiline comments","fromName":"David Kowis","fromEmail":"dkowis@shlrm.org","sentAt":"2006-06-16T17:55:43Z","receivedAt":"2006-06-16T17:55:43Z","isPatch":false,"sender":{"key":"dkowis@shlrm.org","avatar":"https://gravatar.com/avatar/2ebebf02e2dc139286a4ebb90ceda4a07efe0fdb8c3a4c24bc7c1379a1effb4a?d=mp&s=160"},"body":"-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\nDavid Kowis wrote:\n<snip>\n> \n> I'm new to git, but I tried what you said.\n> my git log:\n> commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f\n> Author: David Kowis <dkowis@kain.org>\n> Date:   Fri Jun 16 12:20:08 2006 -0500\n> \n>     this is a multi\n> \n>     line comment\n>     with three lines\n> \n> \n> I'm using git 1.4.0. It added a blank line in there...\n\nI'm going to note that the xorg ML cc doesn't work for anyone not\nsubscribed... You may miss out on replies.\n\n- --\nDavid Kowis\n\nISO Team Lead - www.sourcemage.org\nSource Mage GNU/Linux\n\nProgress isn't made by early risers. It's made by lazy men trying to\nfind easier ways to do something.\n  - Robert Heinlein\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1.4.2 (MingW32)\n\niQGVAwUBRJLwn8nf+vRw63ObAQqhmwv7BXLqVSJa2FV6RVhLnmARqh+MHBAX+XLu\nzgg/kcYd97pXz9bUEFEmY9tp3afzghA6EQlrV/zRHe/R/e1ZFjvTE27mUe3CvtHu\ndUPgx6b85vMLkT2k6jbZ5BoA9KtbNITQlZnQJcEAMBv7aUrclRFykABnXwfh3YxM\njVOGbqoNaKzeB5/Sccb27xnzU91UjztB5X7yNgJYosO6tTz164bQQQbIMGWGztPw\nwTwQOPK2+v4oUqfvYbKlX/Fd/Fve6PPWOAj5cUjxPHf47oiF/HY3ir/V/k04qO34\nKFKAr10ss/sVm7kbURyj7AWJ/putgy9zzYzSWjqh+4ahTwIFb2ciPsU64o1MsO1K\nMnwz0IowmUUZO57qV0gkYdZyPvudOpV2v52aqMEhMyq8GU56Fvsy0KJma235Sv0r\nD0ucIrrorCG0FyY7wKpEM83GJDBaTzxb/Mv8bjCD9/av1uQMjmMvqcPFWsZL+nRx\nigTF8LiWzBBEG5b+PPjKlS8uofj8cW5g\n=90TM\n-----END PGP SIGNATURE-----\n"},{"id":"21911","messageId":"7v7j3gdc7t.fsf@assigned-by-dhcp.cox.net","threadId":"4533","inReplyTo":"4492E8F9.4000106@shlrm.org","subject":"Re: git-rebase nukes multiline comments","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-16T21:25:58Z","receivedAt":"2006-06-16T21:25:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kowis <dkowis@shlrm.org> writes:\n\n> commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f\n> Author: David Kowis <dkowis@kain.org>\n> Date:   Fri Jun 16 12:20:08 2006 -0500\n>\n>     this is a multi\n>\n>     line comment\n>     with three lines\n>\n>\n> I'm using git 1.4.0. It added a blank line in there...\n\nActually, this is an odd but intended behaviour ;-).\n"},{"id":"21916","messageId":"1150494975.DBA8A55@be12.dngr.org","threadId":"4533","inReplyTo":"7v7j3gdc7t.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-rebase nukes multiline comments","fromName":"David Kowis","fromEmail":"dkowis@shlrm.org","sentAt":"2006-06-16T21:56:12Z","receivedAt":"2006-06-16T21:56:12Z","isPatch":false,"sender":{"key":"dkowis@shlrm.org","avatar":"https://gravatar.com/avatar/2ebebf02e2dc139286a4ebb90ceda4a07efe0fdb8c3a4c24bc7c1379a1effb4a?d=mp&s=160"},"body":"\nOn Fri, 16 Jun 2006 16:55, Junio C Hamano wrote:\n> David Kowis <dkowis@shlrm.org> writes:\n>\n>>  commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f\n>>  Author: David Kowis <dkowis@kain.org>\n>>  Date:   Fri Jun 16 12:20:08 2006 -0500\n>>\n>>      this is a multi\n>>\n>>      line comment\n>>      with three lines\n>>\n>>\n>>  I'm using git 1.4.0. It added a blank line in there...\n>\n> Actually, this is an odd but intended behaviour ;-).\n\nWhy is this behaviour intended? Just because I'm curoius. :)\n-- David Kowis - mobile\n"},{"id":"21926","messageId":"7vwtbgbsax.fsf@assigned-by-dhcp.cox.net","threadId":"4533","inReplyTo":"1150494975.DBA8A55@be12.dngr.org","subject":"Re: git-rebase nukes multiline comments","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-06-16T23:21:26Z","receivedAt":"2006-06-16T23:21:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kowis <dkowis@shlrm.org> writes:\n\n>>>  commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f\n>>>  Author: David Kowis <dkowis@kain.org>\n>>>  Date:   Fri Jun 16 12:20:08 2006 -0500\n>>>\n>>>      this is a multi\n>>>\n>>>      line comment\n>>>      with three lines\n>>>\n>>>\n>>>  I'm using git 1.4.0. It added a blank line in there...\n>>\n>> Actually, this is an odd but intended behaviour ;-).\n>\n> Why is this behaviour intended? Just because I'm curoius. :)\n\nYou are not alone; sorry for the terse and confusing initial\nresponse (I am just back from a long flight, finished\nunpacking and quite tired).\n\nAt the lowest level of git that defines the object format, a\ncommit object consists of structural header in fixed format,\nfollowed by any binary blob you feed git-commit-tree from the\nstandard input.  I do not recall the details of the\nimplementation offhand, but we _might_ chomp at the first NUL\nand if we did so I may say it is a bug -- commit-tree should not\ncare what \"the log message\" part consists of.\n\nIt is however quite a different story when it comes to the\nhigher level tools that come with git.  The log summarize\nfacilities to let humans interact with the commits expect that a\ncommit log message consists of a one-line \"summary\", a blank\nline, and then the body of the message.  These \"log listers\" are:\n\n . git log --pretty=oneline\n . gitk\n . gitweb\n . gitview\n . git shortlog\n\nThe \"one-line summary plus body of the message\" has a strong\ncorrelation with how we communicate patches via e-mail.  You do\nnot start a sentence on the \"Subject: \" header and continue on\nto the body of the message, starting the body halfway of the\nsentence.  Instead, you try to make sure you write something\nsensible by itself on the \"Subject: \" header to help the\nrecipient when later scanning for it among bunch of messages,\nand you write a full paragraph that you can understand without\nreading the subject line first.  The following commands that\ndeal with e-mailed patches expect you to follow that convention:\n\n . git am\n . git applymbox\n . git format-patch\n\nNow, answer to your question why rebase bahaves that way are\nbecause:\n\n (1) I was lazy and reused the e-mailed patch machinery to\n     implement it, although rebase is something that _should_\n     work at a level closer to the core level than the human\n     level (e.g. it should be able to commute a patch that\n     affects binary content changes -- which it does).\n\n (2) The user should be following the convention to make the\n     output from the log listers reasonable anyway, so the only\n     people who are harmed by reusing the e-mailed patch\n     machinery were people who did not finish a short-and-sweet\n     summary sentence on the first line, and it is better to\n     train users to do so anyway.\n\nHaving said that, I would say it is a bug.  We should be able to\nrebase, cherry-pick and/or rebase a patch with an arbitrary\nbinary garbage in the commit log message (I think the latter two\ncommand do).  But because of the reason (2) above, it is very\nlow on my priority to change it.\n"},{"id":"22061","messageId":"20060619093623.GA15209@suse.de","threadId":"4533","inReplyTo":"4492F09F.9080906@shlrm.org","subject":"Re: git-rebase nukes multiline comments","fromName":"Matthias Hopf","fromEmail":"mhopf@suse.de","sentAt":"2006-06-19T09:36:23Z","receivedAt":"2006-06-19T09:36:23Z","isPatch":false,"sender":{"key":"mhopf@suse.de","avatar":null},"body":"On Jun 16, 06 12:55:43 -0500, David Kowis wrote:\n> > I'm new to git, but I tried what you said.\n> > my git log:\n> > commit c846bea8c61bec7cf0f7688c48abc42577b9ac7f\n> > Author: David Kowis <dkowis@kain.org>\n> > Date:   Fri Jun 16 12:20:08 2006 -0500\n> > \n> >     this is a multi\n> > \n> >     line comment\n> >     with three lines\n> > \n> > \n> > I'm using git 1.4.0. It added a blank line in there...\n\nO-key. Did this work w/o a blank line as well? Then we can assume this\nsolved in 1.4.0. Now there's still the question whether the log messages\nin the upstream archive can be restored...\n\n> I'm going to note that the xorg ML cc doesn't work for anyone not\n> subscribed... You may miss out on replies.\n\nI'm subscribed here as well :-)\nI just CC'ed xorg so people over there know about the issue as well.\n\nCU\n\nMatthias\n\n-- \nMatthias Hopf <mhopf@suse.de>       __        __   __\nMaxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat@mshopf.de\nPhone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de\n"},{"id":"22062","messageId":"20060619095300.GB15209@suse.de","threadId":"4533","inReplyTo":"7vwtbgbsax.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-rebase nukes multiline comments","fromName":"Matthias Hopf","fromEmail":"mhopf@suse.de","sentAt":"2006-06-19T09:53:00Z","receivedAt":"2006-06-19T09:53:00Z","isPatch":false,"sender":{"key":"mhopf@suse.de","avatar":null},"body":"On Jun 16, 06 16:21:26 -0700, Junio C Hamano wrote:\n> Having said that, I would say it is a bug.  We should be able to\n> rebase, cherry-pick and/or rebase a patch with an arbitrary\n> binary garbage in the commit log message (I think the latter two\n> command do).  But because of the reason (2) above, it is very\n> low on my priority to change it.\n\nI understand. Many thanks for your explainations. I think this intended\nlog format should be documented somewhere, that would help a lot. I\ndon't think that many developers using git in CVS style know about this\nconvention.\n\nSaid that, I assume git nuking the multiline comment was a bug in 1.3.1\nthat has been (somewhat ;) solved.\n\nMatthias\n\n-- \nMatthias Hopf <mhopf@suse.de>       __        __   __\nMaxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat@mshopf.de\nPhone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de\n"},{"id":"22063","messageId":"20060619095444.GC15209@suse.de","threadId":"4533","inReplyTo":"20060619093623.GA15209@suse.de","subject":"Re: git-rebase nukes multiline comments","fromName":"Matthias Hopf","fromEmail":"mhopf@suse.de","sentAt":"2006-06-19T09:54:44Z","receivedAt":"2006-06-19T09:54:44Z","isPatch":false,"sender":{"key":"mhopf@suse.de","avatar":null},"body":"On Jun 19, 06 11:36:23 +0200, Matthias Hopf wrote:\n> On Jun 16, 06 12:55:43 -0500, David Kowis wrote:\n> O-key. Did this work w/o a blank line as well? Then we can assume this\n\nIgnore my ignorance. I really should *read* before answering...\n\nSorry\n\nMatthias\n\n-- \nMatthias Hopf <mhopf@suse.de>       __        __   __\nMaxfeldstr. 5 / 90409 Nuernberg    (_   | |  (_   |__         mat@mshopf.de\nPhone +49-911-74053-715            __)  |_|  __)  |__  labs   www.mshopf.de\n"}]}