I'll keep git bisect in mind, I haven't heard of it before and it seems useful
What I'll miss the most are probably git graphs to keep track (stalk) what's going on in repos (although I haven't tried to get accustomed to git log) Do you think its not useful enough or have you achieved visualizing commit history differently?
I just copy/pasted a fancy git log --graph, and I'm not sure if my eyes like it lol
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.
Agree.
Thanks for your input
I'll keep git bisect in mind, I haven't heard of it before and it seems useful
What I'll miss the most are probably git graphs to keep track (stalk) what's going on in repos (although I haven't tried to get accustomed to
git log) Do you think its not useful enough or have you achieved visualizing commit history differently?I just copy/pasted a fancy
git log --graph, and I'm not sure if my eyes like it lolI 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.