Re: git-annotate bug report

[Ryan Anderson <ryan@michonline.com>]

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