It seems like the order gitk uses for the commits sometimes leads to
overly long lines. My use case is this repository (note that this
svn-conversion is still WIP):

Looking at this with "gitk --all" looks partly like this:
Almost all the commits are in one branch. Rendering the merges at the
top much earlier would avoid this line chaos. Interestingly, if you
just render the relevant commits, it looks fine:
The problem for the current algorithm is probably the single non-merge
commit before the merges.

Another instance in the same repo (again gitk --all) is this part:
Both the pink and right orange line merge from trunk into that kde4
branch. However, this is not obvious from the way it is drawn. I see
this problem is a bit "softly expressed", but I hope you see what I
mean. I think making the merge edges shorter would also make the
actual structure more obvious.

I have no good idea how to easily fix these problems, but I don't know
that much about how it works currently. I see it might involve some
more "intelligence" of the rendering algorithm (forward-looking of
some sort). So never mind if you don't have a fast fix. But I still
wanted to point out that the problem exists.

This might be related to this issue:
git version 1.7.12

Thank you!


To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to