Re: combined diff does not detect binary files and ignores -diff attribute

From: Jeff King <peff@peff.net>
Date: May 25, 2011, 15:29 UTC
Message-ID: <20110525152935.GD8795@sigill.intra.peff.net>
In-Reply-To: <4DDCB203.3020802@drmicha.warpmail.net>

On Wed, May 25, 2011 at 09:38:43AM +0200, Michael J Gruber wrote:

Show 11 quoted lines

> > I agree with Junio that we would need a new config option and external
> > interface for "n-way combined diff". However, isn't what things like
> > vimdiff and meld do the reverse of our combined diff? That is, don't
> > they assume the 3 trees are: ours, theirs, and ancestor (i.e., merge
> > base)? Whereas in a combined diff, it is actually: merge parent 1
> > (ours), merge parent 2 (theirs), and merge _result_.
> > 
> > Also, do those tools generally handle n-way comparisons as opposed to
> > 3-way?
> 
> "Those" tools do "that" which I mean :)

OK, they are more capable than I realized, then. :)

Show 6 quoted lines

> So, in vimdiff, you could in principle change and write any buffer but
> our tools don't support it so far because it is not needed for a merge
> which has one "target" only. In the ui of my dreams, I would have 3
> buffers HEAD INDEX WORKTREE (H I W) and moving hunks between them would
> do all of add -p, reset -p and checkout -p (the HEAD buf would be
> read-only).

This should be relatively easy to implement on the git side, as you are doing the hard parts of the "-p" operation in vim already. You just need to write vim's buffer into the worktree or into the index via hash-object / update-index.

Also, wouldn't you potentially want more than 3 buffers, if you were cherry-picking changes from another commit (as in "git checkout -p $commit" or even putting and taking things from a stash? I think that would be a simple generalization of what you are proposing though.

Show 7 quoted lines

> With "differently abled" tools it could still be useful to have, say a
> tool invoked for the merge HEAD+WORKTREE -> INDEX (with the current
> state of the INDEX as the automatic resolution to start off from) so
> that you can do add+reset -p with your mergetool, and maybe similarly
> for HEAD+INDEX -> WORKTREE. I.e. addtool and checkouttool in addition to
> the difftool and mergetool which we have. Just not for the current
> release cycle any more.

Yeah, getting back to the original discussion. How badly do people actually want an external diff driver that can do fancy things with multiple parents? It seems that for non-text diff viewers, the preferred solution is to use difftool these days (but that is just my impression; I don't use either difftool or external diff drivers).

-Peff