On Thu, Aug 03, 2006 at 04:38:48PM -0400, Jeff King wrote: > git-annotate on the tip of master seems to be broken for some files (but > not for others): Well, I think I've found a few bugs here tonight, basically all are related to handling merges correctly. First, a trivial one: git diff-tree -M --name-status -z outputs the sha1 without honoring the -z. Patch following this email. Second, one I don't know how to fix, at the moment: git annotate uses the automatic tree simplification that git rev-list does. So, when it sees a commit with 1 parent, it assumes that it really only has one parent. git diff-tree -c doesn't know about this same tree simplification, and, in the case of a merge commit, will still output the -c format patch. That particular case is trivial, simply remove the -c from commits where I *know* there is only parent, and ask for the exact diff I need, from the parent to the current rev. There is, unfortunately, another situation, that of an octopus merge. In the case of read-tree.c (after the rename is followed), the commit 7bd1527d2d8c80a6e9a0f8583082a5aee5428c68 is problematic. In it we have a 4-way merge, yet only 3 paths affected read-tree.c. The diff-parsing in annotate constructs a regular expression to find the diff header and read out the line number to work on, and also to construct some regular expressions from which to tell which lines affect which parents. For example, it looks for a line like: + ++Line added in 3 parents with dynamically generated regular expressions. These, of course, need to know how many parents there are. The fact that diff-tree uses a different number of parents makes the parsing fail, and then, the fact that there isn't a great way to figure out which of the real parents corresponds to the pseudo parents, makes this whole thing very messy to fix. So, the solution I've settled on is to use git merge-base to perform some analysis and create a pseudo-parent list that is the same size as the actual parent list, but consisting mostly of the fake parents git-rev-list gives me. If anyone else is confused by this email, it's probably because I stopped and fixed a bug in the middle of writing it. Patches as followups to this. -- Ryan Anderson sometimes Pug Majere - : 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