Re: [PATCH v3 0/5] Expanding tabs in "git log" output

Torsten Bögershausen [off-list ref] writes:

This is copy-paste replacement for the last commit.
(Most probably it is white space damaged)
I'm not sure, is it's worth it ?

Not if you are keeping "expand_tabs_in_log" boolean field.

I was expecting that the new "log-tab-width" thing extends the
expand_tabs_in_log as the concept--it used to be a boolean "do we or
do we not expand?" to "set it to 0 if we do not want to expand, set
it to N if we do want to expand to every N display spaces".  In
other words, if you introduce this new thing, the boolean should not
e necessary and it should go.  Did I misread your earlier message
that described your idea?

+log.tabWidth::
+	Sets the width of a TAB.  If 0, no TAB expansion is done.
+	8 by default.

You need to make it clear where tabs are expanded.  The readers
would wonder if it expands tabs in "log -p" patch output, etc.


A related tangent. I suspect

	git format-patch --expand-tabs-in-log-message=4

might be a good feature to help people whose editors are configured
to move to next-multiple-of-4 column with a tab, and applying their
patch would show unaligned lines in "git log" output for others, by
expanding their tabs when sending the patch out.  We might even want
to add a related option

	git am --unexpand-tabs

that collapses a run of SP that fills to next-multiple-of-8 into a
tab on the receiving end.