Thread (5 messages) flat view 5 messages, 2 authors, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 23:03:58

Possibly related (same subject, not in this thread)

Michael J Gruber [off-list ref] writes:
Junio C Hamano venit, vidit, dixit 03.03.2015 22:26:
quoted
Michael J Gruber [off-list ref] writes:
quoted
+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...:
quoted
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
    ...

    
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help