Petr Baudis [off-list ref] 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 <redacted>
---
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 */