I rarely use graphs, to be honest. But pure visualisation tools are also aplenty, not really a need to switch to a UI-based workflow.
Maybe it's because I work with relatively large concurrent teams that I don't see much point in graphs, but I've never found them to convey relevant information to me. If I need to know how a commit was merged, I can either use our gitlab for the lookup, or some CLI tool that traces back (written one myself once, in fact). I'm also a huge advocate for rebase-before-merge, so our graphs often don't really tell anything. And they break apart regardless of visualization at a certain amount of concurrent branches anyway (bitbucket still can't handle more than a handful of branches properly...).
Besides, once the merge commit is in, it's not really important to know which path a commit took, at least in my experience.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I rarely use graphs, to be honest. But pure visualisation tools are also aplenty, not really a need to switch to a UI-based workflow.
Maybe it's because I work with relatively large concurrent teams that I don't see much point in graphs, but I've never found them to convey relevant information to me. If I need to know how a commit was merged, I can either use our gitlab for the lookup, or some CLI tool that traces back (written one myself once, in fact). I'm also a huge advocate for rebase-before-merge, so our graphs often don't really tell anything. And they break apart regardless of visualization at a certain amount of concurrent branches anyway (bitbucket still can't handle more than a handful of branches properly...).
Besides, once the merge commit is in, it's not really important to know which path a commit took, at least in my experience.