> For now, I'll keep the code as-is, but add more comments to both the > data structure and the code. If I've missed something about how I > could make use of your BEGIN_TREE idea, let me know and I'll look at > it again. In collect_merge_info_callback(), you call setup_path_info() to add to opt->priv->paths, then call traverse_trees() (which recursively calls collect_merge_info_callback()). I was thinking that in addition to doing that, you could call setup_path_info() a second time, but teach it to add a synthetic path (maybe have a special bit in struct conflict_info or something like that) that indicates "this is the end of the tree". Subsequent code can notice that bit and not do the normal processing, but instead do end-of-tree processing. Having said that, maybe it will turn out that your additional comments in v3 will be clearer, and we wouldn't need the synthetic entry.
