Re: git cherry-pick feature request

From: Paul Mackerras <paulus@samba.org>
Date: Aug 24, 2006, 12:54 UTC
Message-ID: <17645.41334.9069.267396@cargo.ozlabs.ibm.com>
In-Reply-To: <7vhd02bn64.fsf@assigned-by-dhcp.cox.net>

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.

Show 12 quoted lines

> 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.