Hi just in case it helps...
Whilst looking at https://next-gitblit.rhcloud.com/summary/gitblit.git I noticed possibly
something I personal thought was a little odd with the tree. I clicked "more commits"
from the main page where I was presented with the first page of commits. At the bottom
the last few commits it show branches being merged in; however, when I click "next"
those branch lines don't appear to continue at the top of the second page. Is that
the expected behaviour?
I realise that those branches may be old and older commits on those branches may not
reappear until a few more pages back. I wonder whether the "gap" could be denoted in
some way? E.g. The branch line would fade out, the line becomes dotted, etc. at the
ends where the rest of the branch cannot be visualised on the next page.
This might just be me but it feels strange to have the tree completely change between
pages. E.g. Going from Page 3 to Page 4 the trees appear to have no relationship (graphically).
Would maybe a "single" page be a good way of displaying the log with a "more" button
at the bottom and behaviour similar to Google Image search when the user clicks that
button, I.e. the next "level" of commits appear underneath and the tree continues.
I realise what I'm suggestion for probably has lots of difficulties to solve in the
detail, just thinking out loud :)
You are correct. It's on my list to review. When you page, the first commit on the
page is used as the root of the tree. This means there is no continuity in the graph
from page to page. :( I do plan to attempt to fix that by collecting 50 or so commits
before the root commit which will make a better looking graph, but it won't be perfect
always. (git makes this harder by having a single linked list of commits, unlike Mercurial
which has a double-linked list). To be completely right, graphing needs to traverse
every commit in a branch which would be quite an expensive operation on large repositories
for a page request. that still might be the way to go, but I haven't benchmarked it.
As for the AJAX idea, it's a good one but probably won't be implemented by me any time
Ok cool. Whilst I was writing my previous post I was already starting to see how solving
this issue would be difficult, especially to "calculate" the correct tree over possibly
large repositories in a timely fashion.
I'll have a look around to see if there are any potential solutions just in case they
might be helpful and I'll post them here.