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

Torsten Bögershausen 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

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

Torsten Bögershausen writes: > On 2016-03-24 19.22, Junio C Hamano wrote: >> Torsten Bögershausen writes: >> >>> Would it make sense to have >>> git log --tab-size=8 >>> (or similar) >>> >>> and add a config variable like >>> git config ui.logtabsize >>> which is

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

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 ? If yes, I can send a proper patch later. git show HEAD commit 3ac551127d51cd59b24f49729d9ce4dd011a09a1 Author: Junio C Hamano Date: Wed Mar 23

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

On 2016-03-24 19.22, Junio C Hamano wrote: > Torsten Bögershausen writes: > >> Would it make sense to have >> git log --tab-size=8 >> (or similar) >> >> and add a config variable like >> git config ui.logtabsize >> which is 0 by default to get the old handling and 8 for the new

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

Torsten Bögershausen writes: > Would it make sense to have > git log --tab-size=8 > (or similar) > > and add a config variable like > git config ui.logtabsize > which is 0 by default to get the old handling and 8 for the new one ? That may be a good approach (I agree with you

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

Torsten Bögershausen writes: >> [5/5] adds a new option --no-expand-tabs that controls the bit 4/5 >>introduces, so that "git log [--pretty] --no-expand-tabs" >>would show the log message indented by 4 spaces, without tab >>expansion. > > Does this

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

> [5/5] adds a new option --no-expand-tabs that controls the bit 4/5 >introduces, so that "git log [--pretty] --no-expand-tabs" >would show the log message indented by 4 spaces, without tab >expansion. Does this introduce an unnecessary regression out of the sudden ?

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

Jeff King writes: > On Wed, Mar 23, 2016 at 04:23:41PM -0700, Junio C Hamano wrote: > >> So here is the third try (previous round is found at $gmane/289166 >> and the very first one is at $gmane/288987). > > Is the plan to merge these as-is? The ordering is a bit funny (introduce

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

On Wed, Mar 23, 2016 at 04:23:41PM -0700, Junio C Hamano wrote: > So here is the third try (previous round is found at $gmane/289166 > and the very first one is at $gmane/288987). Is the plan to merge these as-is? The ordering is a bit funny (introduce breakage, then repair it), and I think the

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

On Wed, Mar 23, 2016 at 4:23 PM, Junio C Hamano wrote: > So here is the third try (previous round is found at $gmane/289166 > and the very first one is at $gmane/288987). > > The first three patches are essentially the same as v2. The last > two updates how the tab-expansion

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

So here is the third try (previous round is found at $gmane/289166 and the very first one is at $gmane/288987). The first three patches are essentially the same as v2. The last two updates how the tab-expansion is internally controlled: [4/5] adds a bit to pretty-commit-context that tells if