From: Junio C Hamano Date: Wed, 01 Feb 2006 00:43:51 GMT Subject: Re: Bottlenecks in git merge Message-ID: <7vvevzoqm0.fsf@assigned-by-dhcp.cox.net> In-Reply-To: <20060131233504.GB31278@pasky.or.cz> Petr Baudis writes: > What about letting the file-handler actually tell merge-index what to > do? merge-index could make a fifo at fd 3 for it (we might fork a > special buffering process for it to avoid PIPE_BUF issues) and let it > write there a sequence of lines like... Yes. That is sensible. A merge handler that is willing to look at the current index stages (and merge-recursive certainly is capable of doing that) can open an outgoing pipe to 'git-update-index --index-info' and drive it. The command syntax is a bit different from what you wrote in your message and I think if we go this route we should make --index-info a bit easier to use by allowing it to accept stage 0 entries. -- >8 -- update-index --index-info: allow stage 0 entries. Somehow we did not allow stuffing the index with stage 0 entries through --index-info interface. I do not think of a reason to forbid it offhand. Signed-off-by: Junio C Hamano --- diff --git a/update-index.c b/update-index.c index 2361e41..94436dd 100644 --- a/update-index.c +++ b/update-index.c @@ -303,7 +303,7 @@ static void read_index_info(int line_ter if (!tab || tab - ptr < 41) goto bad_line; - if (tab[-2] == ' ' && '1' <= tab[-1] && tab[-1] <= '3') { + if (tab[-2] == ' ' && '0' <= tab[-1] && tab[-1] <= '3') { stage = tab[-1] - '0'; ptr = tab + 1; /* point at the head of path */ tab = tab - 2; /* point at tail of sha1 */