Daniel Barkalow [off-list ref] wrote:
I got mostly done with this before Linus mentioned the possibility of
having multiple index entries in the same stage for a single path. I
finished it anyway, but I'm not sure that we won't want to know which of
the common ancestors contributed which, and, if some of them don't have a
path, we wouldn't be able to tell.
I don't have time to look at the patch and I don't have a good
knowledge of the GIT internals, so I will just ask. Does this patch
changes the call convention for git-merge-one-file-script? I have my
own script for StGIT and I would need to know whether it is affected
or not.
Thanks.
--
Catalin
On Wed, 31 Aug 2005, Catalin Marinas wrote:
Daniel Barkalow [off-list ref] wrote:
quoted
I got mostly done with this before Linus mentioned the possibility of
having multiple index entries in the same stage for a single path. I
finished it anyway, but I'm not sure that we won't want to know which of
the common ancestors contributed which, and, if some of them don't have a
path, we wouldn't be able to tell.
I don't have time to look at the patch and I don't have a good
knowledge of the GIT internals, so I will just ask. Does this patch
changes the call convention for git-merge-one-file-script? I have my
own script for StGIT and I would need to know whether it is affected
or not.
Nope, it only changes the trivial merge calling convention within
read-tree.c; I think it's plausible that we might like to add information
at some point, but the short-term goal is just to prevent a few bad cases
in trivial merges.