Re: Command-line interface thoughts

[Michael Nahas <mike.nahas@gmail.com>]

On Thu, Jun 9, 2011 at 5:48 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Wed, 8 June 2011, Michael Nahas wrote:
>> On Wed, Jun 8, 2011 at 11:05 AM, Jeff King <peff@peff.net> 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@gmail.com> 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?
>>
>> 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').

"resolved files" means "NOT conflicted files".  The merge conflicts if
any one file conflicts, but there may be other files that resolve
immediately.  And any conflicted files can be resolved by the user
running "git add" or "git rm"

If a file is resolved - either immediately or by user action - it
exists only in stage 0.

>> 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 assumed most people knew what I meant by <<<<====>>>> blocks.  But,
yes, I meant that the working tree has both versions present at
locations of conflicts.

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

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

> "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 refer you to any of my previous emails to which I kindly replied.
YES, "git diff HEAD" and "git diff HEAD WTREE" would be equivalent.
I, myself, would probably use "git diff HEAD" most of the time.
Nonetheless, saying "git diff" ALWAYS takes two arguments and saying
that if an argument is unspecified that there is a default is much
clearer and more regular interface than special casing everything and
using command-line options to say what you want, which is what we have
now.


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



> --
> Jakub Narebski
> Poland
>