Nguyen Thai Ngoc Duy <pclouds@xxxxxxxxx> writes: > On Tue, Aug 30, 2011 at 4:33 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> and this codepath probably should not be enabled while running a merge > > But do you think if it works with merge (ie. a partial merge)? I highly doubt it. The primary reason why I doubt it would work is actually the same as the very reason why a merge would work with unpack_trees() machinery. It walks all the entries in the trees involved, picking matching entries that would go in the result, while also picking the corresponding entry from the index, and compute their merge and depositing the result in the final index. If you "optimize" it by not walking some parts of trees, you don't just omit merging damages made to these parts by other trees, but you also omit recording the contributions by the current HEAD and the index. You would need to compensate for that by doing something that copies the contents of the index for paths outside the area covered by pathspec. And whole point of this series is not doing that. We don't want to say "because they are outside pathspec, we pretend that these paths in index do not have corresponding entries in the trees we are merging into" and end up producing creation filepairs for them. But I honestly am not interested giving it unnecessary deep thought at this point in the cycle. I haven't found a need for a low-level partial merge machinery implementation to support any higher level workflows in git, and the path-level 3-way merge machinery already exists in the form of ll_merge(). -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html