0

I need to visualize some git branches. However, using gitk or git log --decorate --oneline --graph is insufficient in this case.

The problem is branches wander from column to column in the graph, making it very confusing. Color coding exists but is not enough right now. This is not those tools' fault but another way of looking at the branches may help.

I am not sure what order they would be in, most likely their initial creation date from left to right. So master would always be the left column (no matter what), then whatever branch was made next to the right, etc. (And the number of columns is constant over time, it's just whatever the max number of branches currently is.)

Does such a tool, or arguments to an existing tool exist? Even if there are compromises, it would be very helpful.

Tyler Shellberg
  • 1,086
  • 11
  • 28
  • Branches don't have creation dates. In fact, branches have no meaning at all, and simply record the hash ID of one (1) commit. All meaning comes from your interpretation of the links from each commit to its predecessors, which you follow in order to find the commits, which are the history. Branch names just select a starting point. – torek Oct 22 '19 at 22:44
  • That's great and all but unfortunately does not make the git history any less confusing to look at. Commits have a date attached to them. Should be possible to just find the first commit from a branch. Hopefully a tool will exist to organize this some day. – Tyler Shellberg Oct 31 '19 at 22:18
  • Unfortunately, that doesn't work either. Have a look at [this answer](https://stackoverflow.com/a/3162929/1256452). Branch names come and go; the commits remain. The existence of a name merely provides a way to *find* a commit, without telling you much else, unless you enforce some iron discipline upon al the names in the repository. – torek Oct 31 '19 at 22:23
  • @torek, TortoiseGit (see my response I just posted) is able to create a branch graph without all the diagonal movements just fine. I believe how this works is TortoiseGit runs "git log --topo-order" and uses each commit's **first** parent to backtrack on a branch. If a commit, A, has at least two parents, B and C, then it's a merge commit; commit B would be on the same branch as A and A would be the head of the branch you merged into; and commit C would be the head of the branch you merged from. I know enough about git to tell you that this is how it works 99% of the time if not 100%, anyway. – Darren Embry Jul 19 '20 at 02:57
  • @DarrenEmbry: `git log --graph` (which draws a very crude ASCII graph, not nearly as nice) does the same kind of thing, distinguishing between first and second parents. That's a *topological* view, of branches-as-computed-by-graph—it's not what most people mean when they want to know that when commit X was made, the current branch was named `feature/tall` or whatever. Other version control systems really do record that information and can reproduce it later no matter what; Git doesn't, and therefore can't in general. (That said, the display you posted is MUCH nicer than Git's :-) ) – torek Jul 19 '20 at 15:41

3 Answers3

0

GitHub's Network Graph does this.

Screenshot of GitHub Network Graph

T Percival
  • 8,526
  • 3
  • 43
  • 43
  • Thank you. However, our project cannot be put on github. Does a standalone/offline version of this tool exist? EDIT: It looks like it may actually organize by *author* and not by branch, regardless. – Tyler Shellberg Oct 22 '19 at 22:25
  • Not that I know of. GitHub has private repositories and an enterprise version if you want to inspect secret code. – T Percival Oct 22 '19 at 22:29
  • Regardless, it looks like it actually organizes based on contributor, not on branch. But thank you anyways. – Tyler Shellberg Oct 22 '19 at 22:33
0

TortoiseGit for Windows has a nice visualization tool built in that seems to be what you want. In the explorer context window select TortoiseGit → revision log. You can make sure "All Branches" in the lower left is checked if you want to see the entire repository history.

This is an example of what it looks like. I found it a lot easier to track branches this way too.

Darren Embry
  • 155
  • 1
  • 2
0

there is no simple way to achieve this goal as a branch in git is not a "set of commits" but only a pointer to a specific commit. the previous statement has impact on the way to visualize the git graph.

for example as consequence it means that multiple branches can point to the same commit. and so part of the graph can be shared. we can't also by default only follow the 1st parent of a merge to "follow a branch" as it can be also reversed, for exemple after getting changing from remote by pulling that created a merge commit from the local branch and the tracking branch and immediatly after that by pushing the local that will cause a fast-forward and will reverse the first parent of the remote...

the only way I found to have a readable history in git is the use what is called "linear history" the idea is simple: pull always using rebase update dev branches by rebasing from the source branch deliver to the target branch (only after the dev branch is up-to-date by rebasing it) by merging it (no fast-forward) into the target branch.

this will give you an history that will be like that:

semi-linear history

you can read about that here: https://www.bitsnbites.eu/a-tidy-linear-git-history/

BTW the only git server I found that enforce this behavior is GitLab. They call it semi-linear history

Yosef-at-Panaya
  • 676
  • 4
  • 13