Re: Merge with git-pasky II.

PB> I can't see the conflicts between what I want and what Linus wants. PB> After all, Linus says that I can use the directory cache in any way I PB> please (well, the user can, but I'm speaking for him ;-). So I'm doing PB> so, and with your tool I would get into problems, since it is suddenly PB> imposing a policy on what should be in the index.

I think our misunderstanding is coming from the use of the word "merge tree". I think you have been assuming that I wanted you to run "merge-trees -o ,,merge" --- which would certainly cause me to muck with your dircache there. I totally agree with you that that is a *BAD* *THING*. No question there.

However, my assumption has been different. I was assuming that you would run "merge-trees -o merge~tree" (i.e. different from your "merge tree"), so that you can get the merge results in a form parsable by you. And then, using that information, you can make your changes in ,,merge. After you are done with that information, you can remove "merge~trees", of course.

The format I chose for the "merge result in a form parsable by you" happens to be a dircache in "merge~tree", with minimum number of files checked out when merge cannot be automatically done safely. In the simplest case of not having any conflicting merge between $C and $merged, Cogito can immediately run write-tree in "merge~tree" (not ,,merge) to obtain its tree-ID $T, so that it can feed it to diff-tree to compare it with whatever tree state Cogito wants to apply the merges between $C and $merged to.

I still do not understand what you do in ,,merge directory, but here is one way you can update the user working directory in-place without having a ,,merge directory [*2*]. You can run your "git diff" between $C and $T [*1*]. The result is the diff you need to apply on top of your user's working files. If the user does not like the result of running that diff, it can easily be reversed.

If a manual merge were needed between $C and $merged, Cogito could guide the user through that manual edit in "merge~tree", and run update-cache on those hand merged files in "merge~tree", before running write-tree in "merge~tree" to obtain $T; after that, everything else is the same.

You make interesting points in other parts of your message I need to regurgitate for a while, so I would not comment on them in this message.

[Footnote]

*1* I really like the convenience of being able to use tree-ID and commit-ID interchangeably there. Thanks.

*2* I understand that this would change the user's "git-tools" experience a bit. The user will not be told to "go to ,,merge and commit there which will reflected back to your working tree" anymore. Instead the merge happens in-place. Committing, not committing, or further hand-fixing the merge is up to the user. I suspect this change might even be for the better.