From: Petr Baudis Date: Thu, 10 Nov 2005 20:10:28 GMT Subject: Re: Expected Behavior? Message-ID: <20051110201027.GW30496@pasky.or.cz> In-Reply-To: <46a038f90511101154p4ef99cddv82d56272921a80ac@mail.gmail.com> Dear diary, on Thu, Nov 10, 2005 at 08:54:43PM CET, I got a letter where Martin Langhoff said that... > 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. Yes - from the user standpoint it is supposed to be a foolproof (for a reasonable value of 'fool') and should always guide you around. From a developer's standpoint it might not be entirely crystal-clear, though. ;-) > 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... The design is "keep arbitrary bunch of files in .git recording our state wrt. merging". I want to tidy that up and keep all that in .git/cg-merge-state/ or something. > - 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) Yes, lowercase temp files. Well, the commit msg itself is composed only in cg-commit. > - 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? cg-status and cg-diff are safe anytime, being basically read-only commands wrt. the interesting index information. Well, they _do_ touch your index (but only modifying the stat information), and that may get you into some trouble, but only in case of some seemingly quite rare permission problem, I think (and that will trash your index anytime, not just during a merge). There was a thread about that about a month or two ago, IIRC. > - should cg-status show more about the status of the index ? In what sense? It shows if merge is in progress. It doesn't show conflicts, but that's because... > - how does cg-commit know whether conflicts have been resolved at > all? (perhaps it doesn't even try!) ...we don't actually track them yet. That's considered a bug, I want to fix it, and it even has some non-zero priority. > - how do you reset the 'we are merging' status? cg-reset (except when you were merging over a dirty state; hmm, we don't have a direct command for cancelling that, it seems). cg-merge will now hint you about cg-reset. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ VI has two modes: the one in which it beeps and the one in which it doesn't.