* [PATCH] rev-list: omit duplicated parents.
2006-01-29 20:15 ` Junio C Hamano
@ 2006-01-29 23:30 ` Junio C Hamano
2006-01-31 15:55 ` Possible git-rev-list bug Linus Torvalds
1 sibling, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2006-01-29 23:30 UTC (permalink / raw)
To: Marco Costalba; +Cc: git, torvalds
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
^ permalink raw reply related [flat|nested] 4+ messages in thread* Re: Possible git-rev-list bug
2006-01-29 20:15 ` Junio C Hamano
2006-01-29 23:30 ` [PATCH] rev-list: omit duplicated parents Junio C Hamano
@ 2006-01-31 15:55 ` Linus Torvalds
1 sibling, 0 replies; 4+ messages in thread
From: Linus Torvalds @ 2006-01-31 15:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git
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
^ permalink raw reply [flat|nested] 4+ messages in thread