Torsten Bögershausen <[email protected]> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
