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

From: Junio C Hamano <[email-masked]>
Date: Wed, 04 Mar 2015 13:13:57 -0800

Michael J Gruber <[email-masked]> writes:

> Junio C Hamano venit, vidit, dixit 03.03.2015 22:26:
>> Michael J Gruber <[email-masked]> 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
    ...