Re: [PATCH v2] commit, status: #comment diff output in verbose mode

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

 



Jeff King venit, vidit, dixit 11.03.2011 06:31:
> On Thu, Mar 10, 2011 at 08:23:18PM -0500, Jeff King wrote:
> 
>> I like the proposal for:
>>
>>   # Lines below this one will be removed.
>>   diff --git ...
>>
>> which seems to have the best of both worlds, robust and easy for editors
>> to recognize as a diff. For that matter, we could also do "# Lines below
>> this one..." for _all_ of the git-status template, but I don't think
>> it's necessary. Those lines are already clearly marked with a delimiter,
>> and I don't think anybody is complaining about them (and the "Lines
>> below this one..." line adds just one more line of cruft).
> 
> Hmm, actually the proposal that GÃbor mentioned here:
> 
>   http://thread.gmane.org/gmane.comp.version-control.git/100525/focus=100655
> 
> was to mark the whole status template as "everything below this line is
> uninteresting". And I was wrong that it would add one more line of
> cruft; we already have a line saying "lines with '#' will be ignored",
> so it would be replacing it.
> 
> I do still think I prefer the "#" as comment lines, though. Editors
> understand that concept pretty well. For example, one thing that happens
> to me a lot is that I write a paragraph, then edit it, then ask the
> editor to re-wrap it. Inevitably it buts against the "#" lines, and
> those get re-wrapped, too. I could fix it, of course, but I don't bother
> because the editor knows that the stuff on "#" lines should remain on
> "#" lines. So as it is now, the git-status output gets scrambled, but I
> don't have to care. With a special "# Lines below this one..." line, I
> will have mangled it and get extra cruft in my commit message.

As long as we match for the first n characters of that line with n<60 or
so the rewrapping will do no harm (assuming you leave it to start a new
paragraph, i.e. "^#Lines..." stays "^#Lines...").

> 
> But I admit that this is one pretty bizarre personal anecdote and might
> not affect anyone else.

What affects me more is when when I track files in a different encoding
(latin1, say), the diff triggers that encoding for vim and I end up with
encoding issues for the commit message (which is supposed to be utf8)...

Michael
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[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]