{"thread":{"id":"9699","subject":"[PATCH] Make git-archimport log entries more consistent","startedAt":"2007-08-30T01:56:56Z","lastAt":"2007-08-30T21:46:49Z","messageCount":6,"participants":["Miles Bader","Junio C Hamano","David Kastrup"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"51865","messageId":"617indss2f.fsf@fencepost.gnu.org","threadId":"9699","inReplyTo":null,"subject":"[PATCH] Make git-archimport log entries more consistent","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2007-08-30T01:56:56Z","receivedAt":"2007-08-30T01:56:56Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"When appending the \"git-archimport-id:\" line to the end of log entries,\ngit-archimport would use two blank lines as a separator when there was no\nbody in the arch log (only a Summary: line), and zero blank lines when there\nwas a body (making it hard to see the break between the actual log message\nand the git-archimport-id: line).\n\nThis patch makes git-archimport generate one blank line as a separator in all\ncases.\n---\n git-archimport.perl | 6 +++++-\n 1 files changed, 5 insertions(+), 1 deletions(-)\n\ndiff --git a/git-archimport.perl b/git-archimport.perl\nindex b210772..9e38ba5 100755\n--- a/git-archimport.perl\n+++ b/git-archimport.perl\n@@ -595,8 +595,12 @@ foreach my $ps (@psets) {\n my $pid = open2(*READER, *WRITER,'git-commit-tree',$tree,@par)\n or die $!;\n print WRITER $ps->{summary},\"\\n\\n\";\n- print WRITER $ps->{message},\"\\n\";\n \n+ # only print message if it's not empty, to avoid a spurious blank line;\n+ # also append an extra newline, so there's a blank line before the\n+ # following \"git-archimport-id:\" line.\n+ print WRITER $ps->{message},\"\\n\\n\" if ($ps->{message} ne \"\");\n+ \n # make it easy to backtrack and figure out which Arch revision this was:\n print WRITER 'git-archimport-id: ',$ps->{id},\"\\n\";\n \n-- \n1.5.3.rc3.91.g5c75-dirty\n"},{"id":"51866","messageId":"7vmyw9af3q.fsf@gitster.siamese.dyndns.org","threadId":"9699","inReplyTo":"617indss2f.fsf@fencepost.gnu.org","subject":"Re: [PATCH] Make git-archimport log entries more consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-30T03:14:17Z","receivedAt":"2007-08-30T03:14:17Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Miles Bader writes:\n\n> When appending the \"git-archimport-id:\" line to the end of log entries,\n> git-archimport would use two blank lines as a separator when there was no\n> body in the arch log (only a Summary: line), and zero blank lines when there\n> was a body (making it hard to see the break between the actual log message\n> and the git-archimport-id: line).\n>\n> This patch makes git-archimport generate one blank line as a separator in all\n> cases.\n\nI would not have any problem with what the result of this patch\nwould record in the commits, if it was what it did from the very\nbeginning. But this is a change in behaviour; I'd like to know\nif people who use archimport _rely_ on the current behaviour...\n\nAnybody?\n"},{"id":"51867","messageId":"fc339e4a0708292019s3d4f6914h4f9efe6f1172c380@mail.gmail.com","threadId":"9699","inReplyTo":"7vmyw9af3q.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Make git-archimport log entries more consistent","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2007-08-30T03:19:00Z","receivedAt":"2007-08-30T03:19:00Z","isPatch":true,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"On 8/30/07, Junio C Hamano wrote:\n> > This patch makes git-archimport generate one blank line as a separator in all\n> > cases.\n>\n> I would not have any problem with what the result of this patch\n> would record in the commits, if it was what it did from the very\n> beginning. But this is a change in behaviour; I'd like to know\n> if people who use archimport _rely_ on the current behaviour...\n\nGood point, though it seems pretty unlikely -- the most notable thing\nabout the old behavior was that the results were inconsistent... :-)\n\n-Miles\n\n-- \nDo not taunt Happy Fun Ball.\n"},{"id":"51869","messageId":"7vir6xacha.fsf@gitster.siamese.dyndns.org","threadId":"9699","inReplyTo":"fc339e4a0708292019s3d4f6914h4f9efe6f1172c380@mail.gmail.com","subject":"Re: [PATCH] Make git-archimport log entries more consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-30T04:10:57Z","receivedAt":"2007-08-30T04:10:57Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Miles Bader\" writes:\n\n> On 8/30/07, Junio C Hamano wrote:\n>> > This patch makes git-archimport generate one blank line as a separator in all\n>> > cases.\n>>\n>> I would not have any problem with what the result of this patch\n>> would record in the commits, if it was what it did from the very\n>> beginning. But this is a change in behaviour; I'd like to know\n>> if people who use archimport _rely_ on the current behaviour...\n>\n> Good point, though it seems pretty unlikely -- the most notable thing\n> about the old behavior was that the results were inconsistent... :-)\n\nI think the \"consistency\" is debatable. If somebody was parsing\nthem mechanically, the original code did:\n\n print WRITER $ps->{summary},\"\\n\\n\";\n- print WRITER $ps->{message},\"\\n\";\n print WRITER 'git-archimport-id: ',$ps->{id},\"\\n\";\n\nwhich means the program can read the last line to get id, go\nback to find \"\\n\\n\" and treat the one before it as summary, and\ntake the rest which could be empty as message. That's also\nconsistent.\n\nAfter your change, \n\n print WRITER $ps->{summary},\"\\n\\n\";\n+ print WRITER $ps->{message},\"\\n\\n\" if ($ps->{message} ne \"\");\n print WRITER 'git-archimport-id: ',$ps->{id},\"\\n\";\n\nthe last line is id, go back to find \"\\n\\n\" and use the one\nbefore it as summary, and take the rest as message but (1) if\nthe message is not empty, it is followed by \"\\n\\n\" so the last\n\"\\n\" needs to be stripped, (2) otherwise it is not.\n\nI do not think anybody would doubt that the updated one is nicer\nto the eye. That's why I said it would have been nicer if the\nmessage was formatted like that from the beginning. But I do\nnot think you can claim it is _more_ consistent. It just\nformats under a rule different from the original. The issue is\nif the \"nicer-to-the-eye\" outweighs potential breakage the\nreformatting can cause to existing parsers, if any.\n\nThat's why I wanted to know if people _rely_ on the current\nbehaviour, because I was hoping that everybody would answer \"yes\nnicer-to-the-eye is more important and there is no drawback\".\n"},{"id":"51881","messageId":"86myw9jwga.fsf@lola.quinscape.zz","threadId":"9699","inReplyTo":"7vir6xacha.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] Make git-archimport log entries more consistent","fromName":"David Kastrup","fromEmail":"dak@gnu.org","sentAt":"2007-08-30T07:47:01Z","receivedAt":"2007-08-30T07:47:01Z","isPatch":true,"sender":{"key":"dak@gnu.org","avatar":"https://avatars.githubusercontent.com/u/52141349?v=4"},"body":"Junio C Hamano writes:\n\n> I do not think anybody would doubt that the updated one is nicer\n> to the eye. That's why I said it would have been nicer if the\n> message was formatted like that from the beginning. But I do\n> not think you can claim it is _more_ consistent. It just\n> formats under a rule different from the original. The issue is\n> if the \"nicer-to-the-eye\" outweighs potential breakage the\n> reformatting can cause to existing parsers, if any.\n>\n> That's why I wanted to know if people _rely_ on the current\n> behaviour, because I was hoping that everybody would answer \"yes\n> nicer-to-the-eye is more important and there is no drawback\".\n\nThere are basically two ways to go forward:\n\na) keep the ugly behavior for all eternity\nb) change it and have people adapt dependent tools\n\nIf it is point b), there is not really a migration strategy worth\nnoting. One can formally announce one's intent of changing it for a\nwhile before actually doing it, but given that the previous format was\nnot declared canonical at any point of time, the question is whether\nanyone will indeed notice before things break.\n\n-- \nDavid Kastrup\n"},{"id":"51946","messageId":"7v3ay08zli.fsf@gitster.siamese.dyndns.org","threadId":"9699","inReplyTo":"86myw9jwga.fsf@lola.quinscape.zz","subject":"Re: [PATCH] Make git-archimport log entries more consistent","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2007-08-30T21:46:49Z","receivedAt":"2007-08-30T21:46:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Kastrup writes:\n\n> ... but given that the previous format was\n> not declared canonical at any point of time, the question is whether\n> anyone will indeed notice before things break.\n\nI tend to agree with you. archimport is so specialized that if\nyou are not using it you would not care, and small population\nwho are using it and relying on the old behaviour would notice\nbreakaage right away, so \"Let's see who screams\" sounds like the\nright thing to do.\n"}]}