git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: git-annotate bug report

From
RARyan Anderson <ryan@michonline.com>
Date
Aug 7, 2006, 11:50 UTC
Message-ID
<20060807115000.GC15477@h4x0r5.com>
In-Reply-To
<20060803203848.GA15121@coredump.intra.peff.net>
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
Previous: Ryan AndersonNext: Ryan Anderson
Message 3 of 11 in “git-annotate bug report”
  1. Jeff KingAug 3, 2006
  2. Ryan AndersonAug 3, 2006
  3. Ryan AndersonAug 7, 2006
  4. 1/2 log-tree: show_log() should respect the setting of diffopt->line_terminationRyan Anderson, Aug 7, 2006
  5. 2/2 annotate: Fix bug when parsing merges with differing real and logical parents.Ryan Anderson, Aug 7, 2006
  6. Junio C HamanoAug 7, 2006
  7. Ryan AndersonAug 7, 2006
  8. Annotate another problem reportJunio C Hamano, Aug 7, 2006
  9. Ryan AndersonAug 7, 2006
  10. Junio C HamanoAug 7, 2006
  11. Junio C HamanoAug 8, 2006

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.