Re: Expected Behavior?

[Petr Baudis <pasky@suse.cz>]

Dear diary, on Thu, Nov 10, 2005 at 08:54:43PM CET, I got a letter
where Martin Langhoff <martin.langhoff@gmail.com> said that...
> On 11/11/05, Petr Baudis <pasky@suse.cz> 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.