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

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 25, 2016, 16:41 UTC
Message-ID: <xmqq37re5x33.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <56F5477F.6090600@web.de>

Torsten Bögershausen <tboegi@web.de> 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.