On Sun, Mar 30, 2008 at 04:49:16PM -0700, Junio C Hamano wrote: > What's wrong with "tig -g", I have to wonder... As I mentioned in my initial email, I tried using the graph in tig, but I found it very hard to read. However, going back and taking a closer look at tig, I think its graph is just plain wrong in some cases. For example, here's a comparison of the first several lines of output of "git-graph --date-order --all" and "tig -- --all" in my repository for one of the projects I am working on. I've replaced the commit subjects with just the abbreviated hashes. (Hopefully your mail reader displays this with a monospace font.) git-graph: * 8076867 * 2613e2b M 542f526 |\ * | 642b381 | | * e73dfa2 | \ \ | \ \ M-. \ \ 64e1d85 |\ \ \ \ | | * | | 836521f | | | | | * ce43181 | | | | | * eaeeb08 | | | | | M 79d3db3 | | | | | |\ | | | | | | * da5bc9e | * | | | | | b947aab | | | | | M \ 9ade1bc | | | | | |\ | | | | | * | | | 8f3727b | | | | * | | | 2d102cd * | | | | | | | bf5c6e3 | |/ / / / / / |/| / / / / / * | | | | | | a570370 |/ / / / / / * | | | | | dde9a00 | | | | | * 09048ce | | | | |/ | | | | * 4ee2351 tig (version 0.10.git): + 8076867 * 2613e2b M 542f526 * | 642b381 | | + e73dfa2 M | \ \ 64e1d85 |`.`* | | 836521f | | | | | + ce43181 | | | | | * eaeeb08 | | | | | M 79d3db3 | | | | | |`* da5bc9e | * | | | | | b947aab | | | | | M \ 9ade1bc | | | | * |`.`. 8f3727b | | | | * | | | 2d102cd * | | | | | | | bf5c6e3 *' / / / / / / a570370 *' / / / / / dde9a00 | | | | | * 09048ce | | | | *' 4ee2351 Looking at the tig output, it seems like tig is definitely screwing up around the 3-way merge at 64e1d85. The way I read the output, it looks like it is telling me that commit 836521f is a parent of 542f526, which is incorrect. It also doesn't seem to display things correctly when branch lines need to cross. For example, 836521f is a child of a570370, and b947aab is a child of dde9a00. However, the way I read tig's graph, it looks like it is telling me exactly the opposite--that 836521f is a child of dde9a00 and b947aab is a child of a570370. I think part of the problem is that tig displays exactly 1 commit per line. It's hard to represent octopus merges and crossing branches if it all has to fit in 1 line. This is why git-graph sometimes takes extra lines in between commits to display where the branch lines are going. The git-forest command that Matthieu Moy pointed out also seems to do a good job of representing the graph, while being a bit more compact than git-graph when displaying crossing branches. (I just joined the list in the last couple of days, so I wasn't aware of git-forest. I did try googling for similar tools before I started, but only came up with tig.) -- Adam Simpkins adam@xxxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
