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.
This is something I’ve been looking for for a long time - I’ve never been able to find the right combination of terms; searching for variations of graph drawing never yielded much beyond graphics, and I never did the project I wanted to yet.
I'm curious what's the project you wanted to build ?
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.
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.
> 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.
My biggest problem with rebase is I have often found commits in the middle of a rebased sequence which don't build -- which makes sense as after rebasing you end up with commits which have never been tested, and never "existed" before.
Are you talking about checking out older commits and building them e.g. while doing bisect? Otherwise I can't think of a use case for building commits in the middle of a rebase sequence.
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.
>Unfortunately, the only git clients that draw straight or almost straight branches, GitKraken and SourceTree, are not open-source, thus we will have to design our own algorithm.
Jetbrains Community Edition IDEs have straight branches (I think), and have open-source code.
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...