Re: Bottlenecks in git merge

From: Junio C Hamano <junkio@cox.net>
Date: Feb 1, 2006, 00:43 UTC
Message-ID: <7vvevzoqm0.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <20060131233504.GB31278@pasky.or.cz>

Petr Baudis <pasky@suse.cz> 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 <junkio@cox.net>
---

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 */