Possible git-rev-list bug

In today git archive:

$ git-rev-list --max-count=1 --parents addafaf92eeb86033da91323d0d3ad7a496dae83 -- rev-list.c
addafaf92eeb86033da91323d0d3ad7a496dae83 d8f6b342ae200b2eb72e2f81afea7fe0d41aec0b 93b74bca86f59b8df410b6fd4803b88ee0f304bf d8f6b342ae200b2eb72e2f81afea7fe0d41aec0b d8f6b342ae200b2eb72e2f81afea7fe0d41aec0b 3815f423ae39bf774de3c268c6d3e3b72128a4e5

We have the same parent (d8f6b342ae200b2eb72e2f81afea7fe0d41aec0b) multiple times.

This behaviour causes a wrong graph in qgit and brakes gitk (try 'qgit rev-list.c' or 'gitk rev-list.c' and click on first merge commit).

Please confirm if it's a rev-list bug or it's a 'feature' ;-) in the latter case I will fix qgit.

Marco

___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it

I think it probably is a bug. The commit really has five parents that bundle five independent tracks of development. Two of them touch the specified path since they forked. The rest do not, and for them, the last commit that touched the specified path is behind where they forked:

                  .---o---.
                 /         \
                .---*---o---.
               /   93b74bc   \
  ---*---o---o-----o---o------o addafaf
     d8f6b34   \             /
                .---o---o---.
                 \         /
                  .---*---.
                      3815f42

The "rev-list.c" path limiter is meant to omit "uninteresting" commit, so in this case showing only the three parents after filtering dups would be the right thing to do, I think.

Let me wait for a while to hear Linus contradicts me, though...

Showing the same parent more than once for a commit does not make much sense downstream, so stop it.

This can happen with an incorrectly made merge commit that merges the same parent twice, but can happen in an otherwise sane development history while squishing the history by taking into account only commits that touch specified paths.

For example,

	$ git rev-list --max-count=1 --parents addafaf -- rev-list.c

would have to show this commit ancestry graph:

                  .---o---.
                 /         \
                .---*---o---.
               /    93b74bc  \
   ---*---o---o-----o---o-----o addafaf
      d8f6b34  \             /
                .---o---o---.
                 \         /
                  .---*---.
                      3815f42

where 5 independent development tracks, only two of which have changes in the specified paths since they forked. The last change for the other three development tracks was done by the same commit before they forked, and we were showing that three times.

---

Junio C Hamano <[email protected]> writes:

> I think it probably is a bug...
> ...
> Let me wait for a while to hear Linus contradicts me, though...

I've considered doing this only when path is specified, but instead decided to do so for all commits. I recall there are commits in the kernel archive created somehow with the same parent listed twice, and the downstream tools would have the same trouble if we didn't.

 rev-list.c |   15 ++++++++++++++-
 1 files changed, 14 insertions(+), 1 deletions(-)

d6d9f494403a4e77d17244ece43005eec51200d3

index 0b142c1..93ea41b 100644
@@ -12,6 +12,7 @@
 #define COUNTED		(1u << 2)
 #define SHOWN		(1u << 3)
 #define TREECHANGE	(1u << 4)
+#define TMP_MARK	(1u << 5) /* for isolated cases; clean after use */
 
 static const char rev_list_usage[] =
 "git-rev-list [OPTION] <commit-id>... [ -- paths... ]\n"

@@ -72,9 +73,21 @@ static void show_commit(struct commit *c
 	if (show_parents) {
 		struct commit_list *parents = commit->parents;
 		while (parents) {
-			printf(" %s", sha1_to_hex(parents->item->object.sha1));
+			struct object *o = &(parents->item->object);
 			parents = parents->next;
+			if (o->flags & TMP_MARK)
+				continue;
+			printf(" %s", sha1_to_hex(o->sha1));
+			o->flags |= TMP_MARK;
 		}
+		/* TMP_MARK is a general purpose flag that can
+		 * be used locally, but the user should clean
+		 * things up after it is done with them.
+		 */
+		for (parents = commit->parents;
+		     parents;
+		     parents = parents->next)
+			parents->item->object.flags &= ~TMP_MARK;
 	}
 	if (commit_format == CMIT_FMT_ONELINE)
 		putchar(' ');

1.1.5.g9843f

Well, it's not strictly a bug, and multiple of the same parents _can_ happen in real life due to buggy commits, so a tool that depends on some kind of parent uniqueness are a bit fragile. There is nothing fundamental in the git data structures that says that you couldn't have the same parent twice.

In this case, it didn't start out with the same parent - we had five unique parents, but by the time the tree had been simplified, some of them had become common.

So I don't know if it's a "bug", and the bad reaction by gitk and qgit are arguably the _real_ bugs.

But Junio's patch is simple, and perhaps the right thing to do.

Linus