Re: Expected Behavior?

On 11/11/05, Petr Baudis [off-list ref] wrote:

Well, basically like right now ;-).

Exactly. Which isn't documented, and has several subtleties that I
don't know of.

Merging is a two-stage process, where the two stages are isolated and
the latter does not interfere with the former. The former one is doing
the actual content merge, and that's what cg-merge does. The latter one
is recording the merge in history, and that's what cg-commit does.

There are some semantics to exchange info between cg-merge and
cg-commit and for handling the index while the user is resolving
conflicts or reviewing the merge before committing. I'm not familiar
with them, and I'm unsure what the design is...

 - how do cg-merge and cg-commit pass around the parents, commit msg,
files being merged vs dirty files on tree, etc? (easy: those lowercase
temp files in .git)
 - how do you run cg-status/cg-diff without messing up the index? does
running cg-status or cg-diff stand any risk of accidentally marking
for inclusion dirty files that are not part of the merge? hopefully
not, and then what's the technique?
 - should cg-status show more about the status of the index ?
 - how does cg-commit know whether conflicts have been resolved at
all? (perhaps it doesn't even try!)
 - how do you reset the 'we are merging' status?

Anyway, that's off the top of my head, and probably shows you that I'm
not 200% familiar with all the tricks available for handling the
index.

cheers,



martin