Re: [PATCH v2] config: add --comment option to add a comment

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2024-03-11 20:54, Junio C Hamano wrote:
Dragan Simic <dsimic@xxxxxxxxxxx> writes:

Let me interject...  Perhaps also a tab character before the "#
comment",
instead of a space character.  That would result in even better
readability.
Depends on your screen width ;-)

Ah, screens are pretty wide these days. :)

If you were trying to tell me that SP or no SP is merely a personal
preference with the comment, I think you succeeded in doing so.

Huh, that wasn't my intention.  IMHO, a space character between "#"
and the actual comment is pretty much mandatory.

Ah, OK, you were talking about the gap after the value before the
"#" that introduces the comment, but I somehow mistook it as a
comment about the whitespace after '#'.

Yes, that's what I was talking about.  I'm sorry if the way I wrote it
initially wasn't clear enough.

The gap after the value, I do not have a strong opinion either way
between SP and HT, except that I agree there should be something
there for readability.

I'd vote for a space character after "#", because that's pretty much
the de facto standard.  I don't remember seeing tabs used there.

Given that other places where we do insert comments, like in the log
message editor during "git commit -e", we always give a single space
after the comment character, I tend to agree that a space after '#'
is pretty much mandatory.  It is a non starter to tell users that
they should add their own SP at the beginning if they want to use
such a common style, i.e.

	git commit --comment=' here is my message' ;# BAD

I'd agree with that.  Requiring the users to include a leading space
would make things inconistent.

With a simple rule like "Unless your message begins with '#', the
message is prepended by '# ' (pound, followed by a SP), but when
your message begins with '#', the string is used as is", those who
want to use their own style can use whatever style they want, e.g.

	git commit --comment='#I do not want SP there'
	git commit --comment='#^II want a HT there instead'

and that would be a much more preferrable design, i.e. making the
common things easy, while leaving unusual things possible.

Agreed.  That would be nice.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux