Re: Command-line interface thoughts

On Thu, Jun 9, 2011, Michael Nahas wrote:

On Thu, Jun 9, 2011 at 5:48 AM, Jakub Narebski [off-list ref] wrote:

quoted

On Wed, 8 June 2011, Michael Nahas wrote:

quoted

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

quoted

quoted

quoted

Isn't this going to be behavior change, since your NEXT is not quite the
same as the index?

[...]

quoted

quoted

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_?

Because we merged changed from another branch into HEAD.
Or we pull changes from a remote branch into HEAD.

When a commit is written, it will be part of the branch referenced
by HEAD. 

And by selecting HEAD for diff's NEXT you would have problems with rebase,
where you also can have conflicts, where 'ours' and 'theirs' are switched
around (at least from one point of view).
 

quoted

quoted

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

OURS and HEAD are the same thing, so I doubt a command that does not
involve "HEAD" would behave like "--ours"

OURS and HEAD are not the same thing.  In OURS you have _conflicted_
chunks replaced with HEAD ('ours') version, but chunks that can be
resolved sutomatically are resolved; sometimes to 'theirs' version.

"git diff" in case of conflict prints 3-way combined diff between
'ours', 'theirs' and working area version.  As "git diff NEXT WTREE"
doesn't print 3-way combined diff, it would be different for conflicts
from "git diff".

"git diff --ours" for nonconflicted entry (stage 0 in index) would
print ordinary diff between index and working area, just like
"git diff NEXT WTREE".  What I just realized that at least from what
you wrote (corner case!) in case of conflicts it would be different
from "git diff NEXT WTREE", as ours != HEAD.

[...]

quoted

quoted

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.

N-way merge exists.  It would be bad to say that I was answering a
question about conflicted merges if I didn't produce an answer for
N-way merges.  Unfortunately, I don't have enough information about
N-way merges to answer the question so I decided it was best to
acknowledge my ignorance and that I was giving an incomplete answer.

Actually while git can do n-way merge (so called "octopus" merge), it
either resolves it cleanly, or refuses merge; it does not try to resolve
conflict and present conflicts in the index.  So it is always "3-way
combined diff".

But you didn't answer about _combined diff_...

-- 
Jakub Narebski
Poland