Commit Graph Drawing Algorithms
pvigier.github.io
pvigier.github.io
Preserving Command Line Workflow for a Package Management System using ASCII DAG Visualization(2018) [0]
It's a paper about implementing a new ASCII graph format for dependency management, and it compares existing ASCII graph formats at the front of the paper.
I actually found interesting that many use-cases of ASCII graphs have diverse requirements that one format can't rule all. In particular, usually dependency trees are deep and wide, while git histories are... relatively short and less complex.
Git ASCII graphing format is perfect for denoting graphs without ambiguity, but it becomes too long for most complex graphs, and that's where the paper comes in.
Just a rant, not really super-related... but worth a mention.
[0]: http://www.idav.ucdavis.edu/~ki/publications/graphterm-prepr...
Thanks.
I had a project where I wanted to link commits from different projects. So I could say commit X in repo A depends on commit Y in repo B. And wanted to display the graphs side by side, with the dependencies...
I had some fun trying to replicate the sourcetree algorithm.
https://github.com/alaingilbert/git2graph
The code is ugly, but there is a bunch of tests that could be useful. I also made a basic UI tool to autogenerate tests according to what you draw.
I'm posting it here, maybe someone could find it interesting.
I use to work for some company that has a very strict no-merge, only rebase policy, because they want to preserve a straight-line commit history. But I think what they actually need is an algorithm that can draw / print commit history in straight. To me, altering the model for the sake of view kinda of defeated the purposes.
What purpose?
If the workflow consists of many small fixes/changes that are entirely contained inside a commit or two, there's not really any good reason to merge (with a merge commit) instead of rebase.
For example, with rebase:
- You get a clean linear commit graph for each branch. It's true you can mostly achieve this with merge with some clever merge-commit-collapsing algorithm but that doesn't scale well since each person has his favorite git tool (command line, external git program, built-in git extension of the IDE, etc.)
- The linear commit graph isn't just for eye candy. A lot of git operations are simpler with this type of graph. Want to count how many commits from HEAD you need for interactive rebase? Easy. Want to squash some commits, reordering them, and other complex operations? Easy. It gets a lot more complex when you have merges all over the places.
- Rebase forces the developer to always be on top of the target branch (at least before the pull request is "accepted"). This means conflicts are resolved earlier and the dev is more likely to test his changes with the latest code.
If you care about how the code in a commit(s) evolved to that final state, there's always the code review history in GitHub/GitLab/gerrit/reviewboard/etc.
Merge has its place (e.g. a long-lived feature branch that will eventually be merged into a main branch). But for one-off branch for fixes/small changes you're better off with rebase.
If you don't think this intermediate commits will ever have value, in my opinion you may as well squash them.
I have, on some occasions, run at least basic tests on all commits in a rebased branch but few people bother (and with github, where someone merges a PR by rebase, it would be obvious there was a problem until it was too late).
Wouldn't it make more sense to have the first commit leftmost, closest to master etc. Beyond just feeling more natural to me (reading left to right etc) it'd avoid that huge amount of lines crossing going to the merges, as shown in the smartgit example.
Jetbrains Community Edition IDEs have straight branches (I think), and have open-source code.