On Wed, Jun 8, 2011 at 11:05 AM, Jeff King <peff@xxxxxxxx> wrote: > On Wed, Jun 08, 2011 at 07:39:16AM -0400, Michael Nahas wrote: > >> On Wed, Jun 8, 2011 at 7:12 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> > I don't quite think that we need "git diff NEXT WTREE"; the short >> > and sweet "git diff" is short for a reason, >> >> To be clear, I'm not advocating and have never advocated getting rid >> of zero-argument "git diff". I've advocated that every (whole >> project) diff command should be expressible by a "git diff TREE1 >> TREE2". I'm fine with defaults if one or zero trees are specified. > > I agree with this, but... > >> So "git diff" would default to "git diff NEXT WTREE". > > Isn't this going to be behavior change, since your NEXT is not quite the > same as the index? How do I now get an n-way combined diff of the > unmerged files in the index? > > -Peff The index is a file in .git/ that serves many purposes. NEXT is an image of the whole project. NEXT can be computed from the index and HEAD. During a conflicted merge, stage 0 of the index holds the resolved files. WTREE holds all merge files: the resolved and the unresolved (which have <<<< ==== >>>> blocks in them). I propose that during a conflicted merge, that NEXT be computed as HEAD plus the resolved files, that is, the files in stage 0 of the index. "git diff HEAD NEXT" would print the resolved changes. "git diff NEXT WTREE" would print the unresolved changes "git diff HEAD WTREE" would print all changes. I believe that is the same behaviour as "git diff", "git diff --cached" and "git diff HEAD" during a conflicted merge. I do not know how "n-way" merge works. I saw somewhere that indicated that it was a series of N-1 two-way merges. Mike -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html