From: Martin Langhoff Date: Thu, 10 Nov 2005 19:54:43 GMT Subject: Re: Expected Behavior? Message-ID: <46a038f90511101154p4ef99cddv82d56272921a80ac@mail.gmail.com> In-Reply-To: <20051110193430.GU30496@pasky.or.cz> On 11/11/05, Petr Baudis 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