vitor.hda@xxxxxxxxx wrote on Tue, 17 Jan 2012 00:10 +0000: > On Mon, Jan 16, 2012 at 11:41 PM, Vitor Antunes <vitor.hda@xxxxxxxxx> wrote: > > On Mon, Jan 16, 2012 at 6:57 PM, Pete Wyckoff <pw@xxxxxxxx> wrote: > >> 1. Move the tempBranch commit outside of the "for blob" loop. > >> It can have no parent, and the diff-tree will still tell you > >> if you found the same contents. Instead of a ref for > >> each blob inspected for each change, you'll just have one ref > >> per change. Only one checkpoint() after the tempBranch > >> commit should be needed. > > > > You're right. Completely oversaw that. Will improve the code > > accordingly. > > Apparently I did not oversee it. Assume you have added a new file to > HEAD of parent branch, but you branched from a previous commit. When the > new branch is committed over HEAD the new file will, incorrectly, be > part of it and diff-tree will not work as expected. I don't get it. This algorithm works on the fact that a "branch" in p4 creates a new change that looks exactly like a previous change. The git-p4 sync step, when it detects a branch, starts by saving the change in a commit with parent = null, so it is its own new branch, an orphan, with no parents. Now the task is to find some commit that has an identical tree to this temporary one. You walk back all known p4 commits to try to find one that is the same. It doesn't matter if any of those p4 commits have other commits on top of them. At each step in the backward walk, the comparison is against the unchanged orphan commit. An ascii-art picture might help me. Or even a test case. > I should avoid taking 6 months to submit a patch to avoid forgetting why > I did what I did :) Yeah, and now you have to explain it all over to me again too. :) -- Pete -- 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