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

LT> I'm actually thinking that maybe the _right_ interface is to do something LT> like this:

LT> 	merge-cache <program> <filename>

LT> and what that does is to look up the <filename> in the cache, and if it LT> has any merge entries, unpack all of them (which may be just one file, of LT> course) into up to three separate files (mkstemp()), and then execve the LT> supplied program name with those three files as arguments 1,2,3 (empty LT> argument if no file), and "filename" as argument 4.

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..

One small detail.  What about the "-x" bit?

In case 2 and 3 in your sample merge script, the "merge script" needs to know what the preferred mode bits are before running "update-cache --add".

Yes, it can figure that out by running "show-files --unmerged" and grepping for "$4" by itself, but then it can figure out the information in "$1" through "$3" by itself as well, so that makes having merge-cache wrapper less useful to begin with.

I do not think it is realistic for these three related trees to have files that differ in -x bit, so it would not be that useful to give the "merge script" the flexibility to pick -x bit value among three parents --- it would be fine for the merge-cache wrapper to dictate the value of the -x bit for the resulting file. So I'd suggest to add an extra parameter to the "merge script" when merge-cache wrapper calls it.