vscode-git-graph
vscode-git-graph copied to clipboard
mhutchie
Persistent Branches get a dedicated column
I would like to designate "master", "develop" and other special branches that get their own column for the entire graph. These would should as a single straight line instead of weaving around as the number of branches changes.
Could add an extension setting for Persistent Branches (and perhaps allow a regex for this) and any branch name matching those stays as a straight line?
This would be helpful when trying to visualize the "gitflow" strategy where certain long-lived branches are best kept as a single line with feature with hotfix branches weaving around those major branches. Reference: https://datasift.github.io/gitflow/IntroducingGitFlow.html
Thanks for raising this feature request!
I'll experiment with how this would be implemented, as I've already got some ideas of how the graph rendering algorithm I've written for Git Graph could be modified to achieve this.
Implementing this feature request should also have the effect of achieving the desired behaviour previously requested by two other users, in a way that I believe should be possible. I deemed the previous requests by themselves to not be possible due to the nature of how the graph render algorithm operates, and what they were specifically asking for (whereas I believe that you've presented this feature request in way that should be achieve the same effect).
Me and my team mates need it too...
We are using GitFlow as branching model, in the following scenario:
...the branch named feature/demo_system was rebased on top of develop (via git flow feature rebase command), but i feel that is not so clear (in GitFlow mindset) that is a different branch than develop in this graph.
A good UI fix could be something like this:
...where every branch has his own column, but, i have to say that a more imperative Persistent Branch setting sounds good too.
+3 at least for this feature request, our team would also highly appreciate this!
I came here to request a feature: "Possibility of assigning a color to branch names" For example I wanted to only assign the "red" color to develop, and have everything in different colors. But the solution proposed by OP is actually better.
Looking forward to having this feature soon! 😄
Yes please. Every git graph implementation need this. Like... The yellow artistic representation below shows the develop branch flow in the graph right now at the project I'm working at (sorry for being extremely lazy). We have some extra persistent branches as well right now that would be great to keep ordered (we are working on cultural changes here to minimize this in the future)
BTW, I don't care that the master column for example will be empty to the left most of the time. A suggestion for implementation:
Click on each square for choosing colour and branch. If a branch does not exist anymore, you can just remove that setting on fetching. That would automatize the removal of a feature or release branch I was working with and were already merged into master.
Could add tooltips and an icon to choose or a letter to choose to show in the square
About the problem of color binding branches, maybe you can use "virtual color" ( such as a index number ) rendering first, and then recolor according to the name of the branch?
I've used Git Graph for a week. It's so good that I've started to use VS Code for it and just tossed GitAhead. Nicely done! Thank you.
The only minor nit I have with Git Graph is that the changing column position of graph edges, and the changing colors of branches, are an unnecessary impediment to quickly distinguishing master from other branches. Stable colors (#254) and edge columns (this issue, and especially as in @bergamin's comment) will make it easier to quickly grasp git graphs.
Is Git Graph smart enough to know which commit is on which branch based on merge commit messages?
eg. "Merge branch 'master' into develop" would indicate that the first parent is develop and the second is master
Hi @aNickzz,
Git Graph knows all of the branches which contain a commit ancestor (by traversing the parent/child relationships of commits). However, this is not the same as knowing the branch the commit was on when it was committed (which is what is needed for persistent colouring of commits & branches).
The approach you mentioned would definitely provide the necessary information from the merge commit messages, however I’ve specifically avoided this as commit messages are not designed to be machine parsed. Although most individuals running Git commands would always use the default merge messages, many platforms do not. For example, both GitHub and BitBucket have their own format when merging pull requests that can’t be parsed, and don’t provide the required information. There are also numerous edge cases that don’t work around remote-tracking branches.
That's what I suspected. I know that commit messages aren't necessarily meant to be machine-readable, but it's not unusual for people to impose formatting restrictions on commit messages, eg. for generating a changelog. I've personally never changed the default merge message or been involved in a team that does, so probably I'm too optimistic about what could work.
In the case where the message can be parsed, that would obviously be useful. in the cases where the message can't be parsed, then the most flexible solution would be to allow the user to define some rules, eg.
If merging into master, assume it came from a release branch
If merging into develop, assume it came from a feature branch
Sort the branches by master, release/branch, ..., develop, feature/branch, ... etc.
Going with the first matched rule if multiple would match.
Lest just get persistent branches working for now, after that we can think about categorizing other branches if necessary.
Having persitent branches is a nice feature if you work in a repo for a longer time and got used to the columns. If you switch between repos regularily you have to figure out again which branch is displayed on what column. Therefore I could imagine that having the name of a branch displayed all the time (e.g. vertically on the graph) could be more helpful.
Any update on this? The graph is kinda confusing as is. Was hoping there was some setting to keep main branch static in the graph and all the other branches relative to that, but looks like I'm waiting for this feature.
Was spoiled by Plastic SCM's Branch Explorer:
Made it really easy to visualize the branch flow. Main was always at top. If you had one, dev branch would end up being right under main automatically.
Any update on this?
https://github.com/mhutchie/vscode-git-graph/projects/1
You can follow the progress here.
I've been using git more frequently now and maybe I understand how it works better now than before... Would this implementation even be possible? Because as I understand it, a branch is just like a label that was put on a specific commit. Essentially, branches don't really exist. We would have a commit that has a pointer to the commit prior to it. The moment you have a merge, that backwards pointing will be pointing in two directions. Now which one was develop and which one was the feature? At this point we don't know anymore...
What you say is correct, however something still should be possible, though likely not perfect in all scenarios.
One implementation is to have the "columns" that the legs of the branches fall into sorted left-to-right alphabetically based on the branch name (rather than the current implementation which I believe is based upon commit time). Things might break down a little when multiple branches point to the same commit, but for all other scenarios I think sorting based upon branch name would help to visually keep things in the same places as commits and rebasing happen.
On Thu, Jan 27, 2022 at 3:34 PM Guilherme Taffarel Bergamin < @.***> wrote:
I've been using git more frequently now and maybe I understand how it works better now than before... Would this implementation even be possible? Because as I understand it, a branch is just like a label that was put on a specific commit. Essentially, branches don't really exist. We would have a commit that has a pointer to the commit prior to it. The moment you have a merge, that backwards pointing will be pointing in two directions. Now which one was develop and which one was the feature? At this point we don't know anymore...
— Reply to this email directly, view it on GitHub https://github.com/mhutchie/vscode-git-graph/issues/207#issuecomment-1023616687, or unsubscribe https://github.com/notifications/unsubscribe-auth/AELBIYS2XM4OIC4L3HGNOVTUYGT6TANCNFSM4JJXPCPA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
@jamesmikesell, maybe when merges occur, try a rule like "consider this branch column as being from the receiving side of the merge", or something in this line.
This rule wouldn't work with my depiction of a develop branch in those screenshots I sent previously, but we don't use repositories in that way anymore. We moved to another flow where the only persistent branches are master and develop. In practice only master is persistent really, but in any case, our current flow made this feature unnecessary...
Git Graph knows all of the branches which contain a commit ancestor (by traversing the parent/child relationships of commits). However, this is not the same as knowing the branch the commit was on when it was committed (which is what is needed for persistent colouring of commits & branches).
The moment you have a merge, that backwards pointing will be pointing in two directions. Now which one was develop and which one was the feature? At this point we don't know anymore...
It seems to me a bit of a hidden feature of Git but it is possible to know the commit on the branch before a merge happened because "the first parent of a merge commit is from the branch you were on when you merged (frequently master), while the second parent of a merge commit is from the branch that was merged (say, topic)" (git-scm). In other words: The order of the parent commits tells you which "branch" was merged into another.
With that you can visualize the history like this:
A problem appears only when you fast forward the second branch to the merge commit (also explained here):
Then GitKraken (in this case) can only assume the same ancestor for both branches.
Also see: https://stackoverflow.com/questions/18301284/git-commit-parents-order
@fmeyertoens that means, my last comment is invalid. I don't remember well what the other branches were, but now from your explanation, it seems GitGraph deviated develop in that screenshot in a way that looked like it was merged into another branch when actually it was the other branch which was merged into develop.
Which means the rule suggestion I proposed would actually work in that situation too. Your explanation shows how to achieve that rule
So I've started some work on this, and I think the main stopping force is the sheer complexity of the code. Don't get me wrong, this thing is written very well, but there's so many things to keep in mind. I can easily get off topic about different ways to lower the complexity by rewriting parts of the code, but that's a comment for a different issue.
If you look at my Working File and run it through Quokka, or even any repl or from the CLI, you'll see the output which we should expect when trying to solve this "problem" - main is prioritised to 0, master is prioritised to 1, and the rest are given remaining priorities (from last active onward which is how GG works now). Obviously it's not perfect, because it'll keep stacking rightward as you have more branches/heads, but I'm sure there are algorithms which we can create to determine if a "channel" to the left is being used (heck, it might even be in the code already!).
The main thing that I'm advocating for is a rewrite of some of the Web components - particularly Vertex, Point, Graph, Line, Branch etc. There are so many types that it creates unnecessary complexity, so I'll keep chipping away and pushing commits and maybe accidentally make a GG v2...
TL;DR: https://github.com/TheBrenny/vscode-git-graph/tree/branch_priority has the start of what might become a fix for this issue.
Thanks for listening, I'll get off my box now.
I got a request asking for a bundled version because they were unsure of how to do it themselves. I've bundled and released it on GitHub, so for those looking to do the same (to either test or use, idm), it can be found here:
- VSIX File: https://github.com/TheBrenny/vscode-git-graph/releases/tag/vsix-creation
- Instructions: https://code.visualstudio.com/docs/editor/extension-marketplace#_install-from-a-vsix
@mhutchie 4 years ago this was planned to be implemented... Is there any advance on it or is it going to be discarded?
