git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Ericsson <ae@op5.se>
To: Lars Hjemli <hjemli@gmail.com>
Cc: Marco Costalba <mcostalba@gmail.com>,
	Junio C Hamano <junkio@cox.net>,
	git@vger.kernel.org,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: Possible regression in git-rev-list --header
Date: Thu, 04 Jan 2007 16:21:04 +0100	[thread overview]
Message-ID: <459D1B60.1050604@op5.se> (raw)
In-Reply-To: <8c5c35580701030314t69b6a7dbhf9cb99de4567b93e@mail.gmail.com>

Lars Hjemli wrote:
> On 1/3/07, Marco Costalba <mcostalba@gmail.com> wrote:
>> On 1/3/07, Lars Hjemli <hjemli@gmail.com> wrote:
>> > On 1/3/07, Marco Costalba <mcostalba@gmail.com> wrote:
>> > >         - one blank line
>> > >         - zero or one line with log title
>> > >         - zero or more lines with log message
>> > >         - a terminating '\0'
>> >
>> > I think the should be:
>> >   -zero or more blank lines
>>
>> Isn't it zero or _one_ blank line? Why more then one? would be it
>> useful? surely is slower to parse.
> 
> My point is just that the log message is unformatted. There is nothing
> stopping you from
> adding blank lines at the start of the message.
> 
> But then I tested it, and it seems as 'git-commit' strips off any
> leading blank lines (but git-commit-tree does not). So expecting one
> blank _might_ be good enough.
> 

Other scm's from which we can import repositories have no such 
mechanisms though. It would be nice to have this functionality in 
rev-list. I'm looking into it at the moment.

> 
>>
>> >   -zero or more blank lines
>>
>> Why? this is necessary only to disambiguate muti (non blank) lines
>> titles, but as Junio pointed out distinction between log title and log
>> message is only in the Porcelain, not encoded in git. So the Porcalain
>> is going to show _one_line title if any an the remaining stuff in the
>> log message.
> 
> Well, if the porcelain chooses to do so, it probably is ok. But I
> think the parsing/presentation of the log title/message would be more
> correct/better formatted if the parser is more "adaptive" to the
> content.
> 

I disagree. If the title spans over more than one line, it's most likely 
because it's too long to fit in one, in which case it won't look good 
(or even be viewable in qgit / gitk) when printed anyways.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

  reply	other threads:[~2007-01-04 15:21 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-30 17:56 Possible regression in git-rev-list --header Marco Costalba
2006-12-30 18:30 ` Jakub Narebski
2006-12-30 18:57 ` Johannes Schindelin
2006-12-30 20:20   ` Junio C Hamano
2006-12-30 22:19     ` Junio C Hamano
2006-12-31  1:13       ` Johannes Schindelin
2006-12-31  1:45         ` Junio C Hamano
2006-12-31 11:45           ` Marco Costalba
2006-12-31 15:27             ` Johannes Schindelin
2006-12-31 15:43               ` Marco Costalba
2007-01-01  3:21                 ` Junio C Hamano
2007-01-02 21:32                   ` Johannes Schindelin
2007-01-02 22:13                     ` Junio C Hamano
2007-01-02 22:28                       ` Johannes Schindelin
2007-01-02 22:29                       ` Marco Costalba
2007-01-03  9:21                   ` Marco Costalba
2007-01-03 10:10                     ` Junio C Hamano
2007-01-03 10:21                     ` Lars Hjemli
2007-01-03 10:35                       ` Marco Costalba
2007-01-03 11:14                         ` Lars Hjemli
2007-01-04 15:21                           ` Andreas Ericsson [this message]
2007-01-04 15:18                         ` Andreas Ericsson
2007-01-03 10:38                       ` Lars Hjemli
2006-12-31  0:37     ` Johannes Schindelin
2006-12-30 20:22   ` [PATCH] Move commit reencoding parameter parsing to revision.c Junio C Hamano
2006-12-31  1:10     ` Johannes Schindelin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=459D1B60.1050604@op5.se \
    --to=ae@op5.se \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=hjemli@gmail.com \
    --cc=junkio@cox.net \
    --cc=mcostalba@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).