Re: git cherry-pick feature request

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: git cherry-pick feature request

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:37

Paul Mackerras [off-list ref] writes:
While I'm asking for features, another one that would be really useful
for another tool I'm writing is a 3-way diff for a file between the
working directory, the index, and the current head commit, something
like what git diff-tree -c does for merges.  That is, it would have
two columns of +/-/space characters, one for the current head and one
for the index.  A '-' would indicate that the line appears in the
current head or the index but not in the version of the file in the
working directory.  A '+' would indicate that the line appears in the
working directory version.
The combined diff (-c and --cc) comparison works by comparing a
single post-image (merge result) with multiple pre-images, so I
think it is reasonable to compare the working tree files as the
post-image and cached and HEAD-tree versions as the preimages.

I am not sure how useful this would be though -- I am guessing
that in most people's workflow the index and the HEAD would
exactly match most of the time, since that is the way Linus
encourages (and I follow that myself).  So for that extreme use
case, the difference between "diff-index HEAD" and the proposed
command (I am thinking about calling it git-diff-status) would
be that the latter always has two plus or minus signs instead of
one, and lines with a single plus or minus would be an
indication that HEAD and index have drifted.  In other words,
the largest benefit of "combined diff" which is to simplify
trivial "The result took this one not that one wholesale"
differences would not be felt.

I have to visualize the result a bit before coding this.

Re: git cherry-pick feature request

From: Paul Mackerras <hidden>
Date: 2016-06-15 22:42:37

Junio C Hamano writes:
The combined diff (-c and --cc) comparison works by comparing a
single post-image (merge result) with multiple pre-images, so I
think it is reasonable to compare the working tree files as the
post-image and cached and HEAD-tree versions as the preimages.
Yes, I think that is probably the most useful way around.
I am not sure how useful this would be though -- I am guessing
that in most people's workflow the index and the HEAD would
exactly match most of the time, since that is the way Linus
encourages (and I follow that myself).  So for that extreme use
case, the difference between "diff-index HEAD" and the proposed
command (I am thinking about calling it git-diff-status) would
be that the latter always has two plus or minus signs instead of
one, and lines with a single plus or minus would be an
indication that HEAD and index have drifted.  In other words,
the largest benefit of "combined diff" which is to simplify
trivial "The result took this one not that one wholesale"
differences would not be felt.
The tool I am writing knows whether the index matches the HEAD or the
working directory, and uses a simple git diff-index -p in those
cases.  The only time when the 3-way diff would be needed is when the
user wants to commit a subset of the changes in the working version,
because then the index (== changes to be committed) would be different
from both the HEAD and the working directory.

I could just do the two diffs and combine them in Tcl; I have done
that sort of thing in dirdiff.  It gets a bit complicated though, and
given that we already have C code for an N-way diff, I thought it made
sense to reuse it.

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