Possible git-rev-list bug

Possible git-rev-list bug

[Marco Costalba]

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

Re: Possible git-rev-list bug

[Junio C Hamano]

Marco Costalba <mcostalba@yahoo.it> writes:

> $ 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.

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...

[PATCH] rev-list: omit duplicated parents.

[Junio C Hamano]

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.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

    Junio C Hamano <junkio@cox.net> 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
diff --git a/rev-list.c b/rev-list.c
index 0b142c1..93ea41b 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -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

Re: Possible git-rev-list bug

[Linus Torvalds]

On Sun, 29 Jan 2006, Junio C Hamano wrote:

> Marco Costalba <mcostalba@yahoo.it> writes:
> 
> > $ git-rev-list --max-count=1 --parents addafaf92eeb86033da91323d0d3ad7a496dae83 -- rev-list.c
> > addaf.. d8f6b.. 93b74.. d8f6b.. d8f6b.. 3815f..
> >
> > We have the same parent (d8f6b..) multiple times.
> 
> I think it probably is a bug.

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