Re: Command-line interface thoughts

On Wed, 8 June 2011, Michael Nahas wrote:

On Wed, Jun 8, 2011 at 11:05 AM, Jeff King [off-list ref] wrote:

quoted

On Wed, Jun 08, 2011 at 07:39:16AM -0400, Michael Nahas wrote:

quoted

On Wed, Jun 8, 2011 at 7:12 AM, Jakub Narebski [off-list ref] wrote:

quoted

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

quoted

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?

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.

It is simply not true.  During a conflicted merge, for conflicted files
there is _no_ stage 0!!!  Conflicted files have stage 1 == base, 2 == ours
and 3 == theirs, where those stages have all conflicts that can be resolved
automatically resolved, and places where there is conflict replaced by
merge-base ('base'), current branch into which we merge ('ours') and
merged branch ('theirs').

WTREE holds all merge files: the resolved and the unresolved 
(which have <<<< ==== >>>> blocks in them).

Worktree version has files with conflict merge markers added in place
where there is conflict.

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.

Why _HEAD_?
 

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

"git diff NEXT WTREE" would not behave (with your proposal) like
"git diff", but like "git diff --ours".

"git diff HEAD NEXT" would not behave like "git diff --cached"
(which shows only '*Unmerged path foo').

"git diff HEAD WTREE" would be the same as "git diff HEAD" (just
longer to write), only because it doesn't involve index at all.
 

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.

Where this "n-way merge" came from?  Peff wrote about "n-way combined
diff", which is something different.

-- 
Jakub Narebski
Poland