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