Thread (4 messages) flat view 4 messages, 3 authors, 2016-06-15

RE: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

From: Randall S. Becker <hidden>
Date: 2016-06-15 23:08:45

On March 15, 2016 8:17 PM Linus Torvalds wrote:
So I end up doing this manually when I notice, but I was wondering ig maybe
git could just have an option to "git am" and friends to de-tabify the commit
message.

It's particularly noticeable when people line things up using tabs (for the
kernel, it's often things like "cpu1 does X, cpu2 does Y"), and then when you
do "git log" it looks like a unholy mess, because the 4-char indentation of the
log message ends up causing those things to not line up at all after all.

The natural thing to do would be to pass in a "tab size" parameter to
strbuf_stripspace(), and default it to 0 (for no change), but have some way to
let people say "expand tabs to spaces at 8-character tab-stops" or similar
(but let people use different tab-stops if they want).

Do people hate that idea? I may not get around to it for a while (it's the
kernel merge window right now), but I can write the patch eventually - I just
wanted to do an RFC first.
Speaking partly as a consumer of the comments and partly as someone who generates the commits through APIs, I would ask that the commit tab handling semantic be more formalized than just tab size to strbuf_stripspace(). While it might seem a bit unfair to have to worry about non-git git clients, the detabbing can impact the other commit implementers (e.g., SourceTree, EGit, JGit, and the raft of process automation bits out there using JGit for cool stuff). Personally, I would prefer to have a normalized behaviour so that any bit of automation building a commit message would have a specific definition to go to (and hopefully comply with) in order to properly format the message for posterity and across all consumers. It might also be useful to have some ability to be presentation-compatible 
 with legacy commits (done after this type of enhancement) so that a reasonable presentation can be done for those 8 year old commits that still have embedded tabs. Personally, I don't encourage tabs in commits myself and do see the value of this, but is this really restricted just to git am?

Just my $0.02,

Randall

-- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(211288444200000000)
-- In my real life, I talk too much.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help