Re: [PATCH] "checkout-cache -m" writes unmerged contents for each stage.

[Junio C Hamano <junkio@cox.net>]

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:

LT> On Sun, 17 Apr 2005, Junio C Hamano wrote:
>> 
>> This is the alternative strategy I mentioned in my previous
>> message.  A new -m option to checkout-cache causes it to store
>> contents of unmerged paths in path~1~, path~2~, and path~3~.

LT> I don't think this is wrong, but it all seems a bit hacky. The reason I 
LT> didn't apply your other patch was that I just don't feel quite comfortable 
LT> with what is the RightThing(tm) to do yet.

I do not personally like that '-m' thing either so please feel
free to drop it.  I was just toying with the idea.  I knew you
would not use "-m" yourself (and I would not myself either).
The patch was primarily meant for Pasky to raise his opinion.
If having something like this helps Cogito then he can keep it.
If Cogito will be doing the "show-files --unmerged" with
"cat-file blob" itself and this "checkout-cache -m" does not
help it that much then there is no point having this hack.

LT> I'm actually fairly certain that the right thing to do is to silently 
LT> ignore all unmerged entries. They just aren't "interesting" from a 
LT> checkout-cache perspective, least of all when given the "-a" flag. So even 
LT> warning about them seems to be pointless.

I do not mind your dropping the "warning" bit, but please keep
the skipping bit for "-a".  Dropping that TT from stage 1 into
the working directory and then complaining that TT exists when
it then tries to extract stage 2 and stage 3 is simply madness.

LT> What do you think? I can whip up a "merge-cache" program like that in five 
LT> minutes, and it _seems_ like the right interface..

Yes.  I think that is the right thing to do.  In fact the idea
is quite similar to what I've been working on, which is a
rewrite of that perl thing to use "read-tree -m O A B".