Clone http://hg.mozilla.org/comm-central/Scroll down to revision 5624.
Then, very slowly, scroll down to revision 5620.
Notice how the line pops in and out as you go back and forth between those two revisions.
Ahh... Not a bug, or at least something that I don't see how to change. Just like Mercurial, when I do a graph representation I only look so far into the future and so far into the past. If not sometimes for a big repository there would be say 1000 different branchings and all the branches in the graph would be squished to the left.
Thus the graph has to be a local graph. And the graph extends off screen by a certain count which seemed appropriate in testing... I think its 10 revisions forward and 10 back or something I could look up the code...
Then simply when you are scrolling at one point the graph is a straight line with no branchings, and then a little later when you scroll down a bit, the graph has branchings (or vice versa), so horizontally the graph is shifted. Thus the jiggling is intentional.
Resolution: As designed. (I wish I could change bitbuckets classification from invalid but its the closest thing that matches.)
Perhaps the graph has to be a local graph, but I think that if you have data from a previous scroll, you could use it to get things to move around less.
Also, is there a way for me to find out what calls you're making to get the data that you use to create the graph? I'ld like to look through it by hand, and see what's changing.
I agree with Blake; this is a serious usability problem that doesn't need to be there (see Murky.app for example, or any number of similar history viewers for Git). A related problem is that the colors assigned to individual branches/heads aren't kept consistent.
Dave, can I get you to file a new bug about the color of the branch. That is a bug and can be made to work. The problem with keeping the graph static in its columns is that in bigger repositories there is often many many branches in parallel. Especially if it is a busy repository. If you have the width of the graph being defined by the maximum branches the branches soon all bunch up into just one thin line. (I originally had it static but when I went looking at large systems all the history got scrunched up.)
The graph *has* to be local to deal with larger systems. Murky currently can't deal with larger systems at all. Eg try opening http://hg.services.openoffice.org/hg/DEV300 in murky and it just hangs. I will post the example system I used which had a ton of branchings to illustrate this point later...
And here's a video showing the problem: http://bwinton.latte.ca/temp/bouncing.mov I would love to try to figure out why everything is moving around like that, given that there aren't a lot of branches, and when the branch is actually shown, it doesn't move around.
Ok... Ok... :) :) I'll think about how we can do this if we have a continuous connection from one point to another. But for instance if the repository has some 200,000 changesets, if you jump to the middle you just do not have the time to build the full graph for 200,000 changesets and still be vaguely interactive in your responses.
Thus at the very least the graph has to start locally... I think I can code it so it stays the same color, I am just not sure about the jiggling:
Which basically starts at the highest revision in the limit and works its way down to the lowest revision in the limit. The limits are determined in:
- (LowHighPair) logGraphLimits
And in here I can probably look at where we have been historically.
Or I could cache the column of the node, but doing this gives other undesirable behavior... One consequence is that the main "trunk" is not always in column zero... But I have heard the complaints... I'll do something ;)
I just wanted to say that this is a major issue for me, although I understand it's not necessarily easy to fix.
As the repo I work with is very branchy, the dancing graph makes it impossible to follow a branch back to its source. The changing order of branch thread is especially jarring, but even just adding/removing threads sends my head for a loop.
I don't care if the diagram is consistent if I jump from revision to revision, but it must stay consistent, or at least animate removing / adding a branch, while scrolling.
Anything as long as it allows branches to be traced by eye when they run over several screens.
Thanks for your comment... I'll definitely try and fix this somehow... I just don't know exactly how yet :) On the repo example you gave with some 200,000 commits its one of those examples where you just can't precompute the entire graph before drawing local history... I'll think of something :)
I would think that if you stored the position and colour of the nodes you had calculated, then you could use that when calculating what position and colour new nodes should get.
(And if you can point me at the code that tries to determine all of this, I'll be happy to take a stab at it.)
Ok I have done work on this. It has basically required a complete rewrite of LogGraph.m and I have something going now but it still has bugs in it, eg the incomplete revision is not totally correct, and a few other things. But sometime in the near future I'll release a new version with these changes...
Please, please fix this.
I just wanted you to know that this is a complete deal breaker for me. I'm not trying to be a ungrateful or harsh, MacHg is the best Hg client for Mac hands down, but this problem makes it almost useless, because as other have said, you can't follow a branch, you simply get lost because of all the jumping. If you work with several people, following branches to their source is essential. As it is I have to resort to hg serve to get a clear picture of the repo.
I'm used to TortoiseHg in both Windows and Linux and it works perfectly in this regard. Maybe it has to do with Tortoise only loading a subset of the changesets at a time. Perhaps you could take a look at their code.
Again, please don't take it the wrong way, you've done a great work, but this is a very important issue.
Issue #119 was marked as a duplicate of this issue.
I'd also like to state that me and my colleagues find the graph very beautiful but of limited usefulness since the jiggling makes it impossible to follow a branch. Have to fall back to "hg log -G" for that. If you could improve on this issue we'd be really grateful. Maybe it's possible to chose the color according to the branch, so that at least the color is consistent, that would already help a lot. Thanks a lot.