>>>>> "LT" == Linus Torvalds <[EMAIL PROTECTED]> writes:
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
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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html