patchMake git-archimport log entries more consistent

When appending the "git-archimport-id:" line to the end of log entries, git-archimport would use two blank lines as a separator when there was no body in the arch log (only a Summary: line), and zero blank lines when there was a body (making it hard to see the break between the actual log message and the git-archimport-id: line).

This patch makes git-archimport generate one blank line as a separator in all
cases.
---
 git-archimport.perl |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

Miles Bader <miles@gnu.org> writes:

I would not have any problem with what the result of this patch would record in the commits, if it was what it did from the very beginning. But this is a change in behaviour; I'd like to know if people who use archimport _rely_ on the current behaviour...

Anybody?

On 8/30/07, Junio C Hamano <gitster@pobox.com> wrote:

Good point, though it seems pretty unlikely -- the most notable thing about the old behavior was that the results were inconsistent... :-)

-Miles

"Miles Bader" <miles@gnu.org> writes:

I think the "consistency" is debatable. If somebody was parsing them mechanically, the original code did:

     print WRITER $ps->{summary},"\n\n";
-    print WRITER $ps->{message},"\n";
     print WRITER 'git-archimport-id: ',$ps->{id},"\n";

which means the program can read the last line to get id, go back to find "\n\n" and treat the one before it as summary, and take the rest which could be empty as message. That's also consistent.

After your change, 

     print WRITER $ps->{summary},"\n\n";
+    print WRITER $ps->{message},"\n\n" if ($ps->{message} ne "");
     print WRITER 'git-archimport-id: ',$ps->{id},"\n";

the last line is id, go back to find "\n\n" and use the one before it as summary, and take the rest as message but (1) if the message is not empty, it is followed by "\n\n" so the last "\n" needs to be stripped, (2) otherwise it is not.

I do not think anybody would doubt that the updated one is nicer to the eye. That's why I said it would have been nicer if the message was formatted like that from the beginning. But I do not think you can claim it is _more_ consistent. It just formats under a rule different from the original. The issue is if the "nicer-to-the-eye" outweighs potential breakage the reformatting can cause to existing parsers, if any.

That's why I wanted to know if people _rely_ on the current behaviour, because I was hoping that everybody would answer "yes nicer-to-the-eye is more important and there is no drawback".

Junio C Hamano <gitster@pobox.com> writes:

There are basically two ways to go forward:

a) keep the ugly behavior for all eternity b) change it and have people adapt dependent tools

If it is point b), there is not really a migration strategy worth noting. One can formally announce one's intent of changing it for a while before actually doing it, but given that the previous format was not declared canonical at any point of time, the question is whether anyone will indeed notice before things break.

David Kastrup <dak@gnu.org> writes:

I tend to agree with you. archimport is so specialized that if you are not using it you would not care, and small population who are using it and relying on the old behaviour would notice breakaage right away, so "Let's see who screams" sounds like the right thing to do.