Parent discrepancy between knits and revisions

John Arbash Meinel john at
Wed Apr 11 00:04:23 BST 2007

Aaron Bentley wrote:
> Hi all,
> I've discovered a discrepancy between the parents of a file's knit, and
> the revision.
> Take  The following file versions have >2 parents according
> to the kint:
> robertc at
> robertc at
> robertc at
> But according to cat-revision, the actual revisions have only two parents.
> For revision robertc at
> The revision parents are:
> robertc at
> abentley at
> The parents are:
> abentley at
> abentley at
> robertc at
> robertc at
> I would have imagined it could be the other way around, due to ghosts.
> But it's hard for me to see a benign explanation for this.
> Aaron

I'm trying to look into this. I ended up writing:

To try and help. It is sort of like 'graph-ancestry' but it focuses on a
specific knit, and lets me supply a --start and --end so that I can
actually view the final image. (my machine seems to want to use 500+MB
for a 600 node graph, much less a 10k graph from all of

Anyway, the specific knit graphs seem quite a bit different than the
global ones. For example the revision:
robertc at

Is very important in '', in that 6 revisions seem to decend
from it. But in the revision message is only:
  lalos branch constructor patch

I'm guessing it was Robert's integration branch. One of the decendents was:
  john at
with message:
  Most tests pass, some problems with unavailable socket recv
with only 1 parent:
  john at

Now, I understand this, because probably my branch derived from Robert's
integration branch, and I didn't make any changes to until

So I'm still trying to understand your octopus merge, but my guess is
that it is something like... both sides have merges and both of the
merges modify the file.

For example (see attached):
digraph G {
  a -> c;
  b -> c;
  d -> f;
  e -> f;
  c -> g;
  f -> g;

In this case, 'g' would show changes from a, b, d, e (maybe) without
requiring an octopus merge at g.

Now, I'm not positive, because it seems like c and f would have to
record content changes to resolve the merge, so you would still only end
up with 'c,f'.

The other possibility is that it is just a bogusity with our early merge
detection code, considering all of these nodes are fairly old. (Though
that could also be because we worked in more of a mesh before
had multi-committer support).

Probably my next step would be to overlay 2 knit graphs (so you can see
the overall branch history and an individual file history).

So I don't have any easy answers (yet :).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: mygraph.png
Type: image/png
Size: 1540 bytes
Desc: not available
Url : 

More information about the bazaar mailing list