Re: [PATCHv2 2/2] commit/status: show the index-worktree diff with -v -v

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 4, 2015, 21:13 UTC
Message-ID: <xmqqr3t479ey.fsf@gitster.dls.corp.google.com>
In-Reply-To: <54F6E87F.2010605@drmicha.warpmail.net>

Michael J Gruber <git@drmicha.warpmail.net> writes:

Show 32 quoted lines

> Junio C Hamano venit, vidit, dixit 03.03.2015 22:26:
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>> 
>>> +diff --git INDEX=staged-for-commit/dir1/modified
>>> WORKTREE=not-staged-for-commit/dir1/modified
>>> +index e69de29..d00491f 100644
>>> +--- INDEX=staged-for-commit/dir1/modified
>>> ++++ WORKTREE=not-staged-for-commit/dir1/modified
>> 
>> This might be OK for a project like Git itself, but I suspect people
>> with long pathnames (like, eh, those in Java land) would not
>> appreciate it.
>> 
>> Wouldn't mnemonic prefix, which the users are already familiar with,
>> be the most suitable tool for this disambiguation?  After all that
>> was what it was invented for 8 years ago.
>
> Well...:
>
>> or it may want to even be like this:
>> 
>> 	diff --git a/A b/A
>>         ...
>>         diff --git to-be-committed/A left-out-of-the-commit/A
>>         ...
>>         diff --git a/B b/B
>>         ...
>> 
>> by using a custom, unusual and easy-to-notice prefixes.
>
> Your idea was to use these verbous prefixes so that one recognizes the
> different types of diffs, and so that we don't need to sort them by file.

Yeah, but I can become wiser over time and change my opinion, no ;-)?

As to pairing the diffs by paths so that c/i and i/w diffs for the same path come together, which I mentioned in the older message you quoted, I think what you said in response made sense, i.e. "the intention was to show the diff for the two categories of changes which "git status" lists without diff already". So I'd prefer showing c/i diff and then optionall i/w diff like you did, without mixing them together.

> I'm happy with c/,i/ and i/,w/ and without sorting. Maybe we would need
> headings between the two diffs then?

Yup. The i/w diff is a new thing and a heading before it to explain what it is would be very helpful for the users to understand what they are looking at. A new heading before c/i diff might help but it may be OK without. E.g. something along the following lines

    Changes to be committed:
        modified: foo

    Changes left in the working tree:
        modified: bar

    --------------------------------------------------
    Changes to be committed
    diff --git c/foo i/foo
    ...

    
    --------------------------------------------------
    Changes left in the working tree
    diff --git i/bar w/bsar
    ...