I absolutely love, and recommend to any new team members, GitX [0] and other similar Git visualizers. It's incredibly valuable to be able to instantly see the Merkle Tree drawn out and say "oh, the reason my current HEAD isn't picking up thing X that I thought I'd merged in, is because thing X isn't visually an ancestor of my HEAD even though temporally it might have happened earlier than my most recent commit."
I see newer engineers struggling to memorize "what Git command corresponds to my current situation" all the time, and they're missing the intuition that it's all a very simple graph under the hood. Github, I think, does a disservice by trying to present commits as a linear list - while certainly it's easier to code a linear visualization, it makes people feel like Git is impenetrable magic, when it's anything but.
(Full disclosure: my love of visualizations of commit graphs may very much be influenced by the game Fringer [1], which was a formative part of my childhood!)
> I see newer engineers struggling to memorize "what Git command corresponds to my current situation" all the time, and they're missing the intuition that it's all a very simple graph under the hood.
The reason I have run into this has almost always been because what I want is “take this commit and move it here” and the command for it is some sort of git frobnicate --cached --preserve-stashed that you look up online. “It’s a graph” is great and takes like thirty seconds to explain but once you get that done with it provides almost no insight in how you’re actually supposed to interact with the porcelain to get that graph in the state you want it to be.
In the simple case, yes. But what if it’s a merge commit? What if there is a conflict and I actually want the result to split into two clean diffs that I’ll specify (so that both compile, of course). What if I want it inserted somewhere in the middle of a branch? What if the branch doesn’t exist yet but I want to do this to a remote branch without having to check out something new locally? What if I want to apply the change but lie about the author?
Git is able to do all these things, and I am actually quite pleased that it can support all of these strange workflows. But it still isn’t at all obvious how you’d get these to work if you know the operation to apply a commit was “git cherry-pick”. (I have also noticed that “git rebase” is often a, if not the answer to every “how do I fix my tree” question. But it’s certainly not advertised as such, which is beyond me.)
Right, if you want something complicated then it will be complicated, but saying that “take this commit and move it here” is complex is definitely false.
The point I’m trying to make is that I’m very opposed to people who go “the tree is so simple, if you understand it you’ll know how to use Git”. No, the tree is simple, the tools to work with it are not. None of the things I described have complicated end states, because in general you can’t tell how much work goes into getting to a particular from the final graph you get out of it.
not to be trite but the end result of this intuitive system seems to be to bolt on even more math and made up acronyms - both of which beginners really struggle with and most non college educated journeymen devs misunderstand coz of the esoteric nature of their education.
Strong agree for git rebase. When I write docs/teach folks about git, I almost never even mention merging. It's just generally very rarely useful, and I find it kind of makes git as a whole more of a black box. "git rebase -i" gives a much clearer picture of what's happening, and will let you solve significantly more complicated problems with the same tools and mental model.
TRIED: git log —-graph —-oneline —-decorate
GOT:
fatal: ambiguous argument '—-graph': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
Retype the dashes, you've posted something different to GP, em dash en dash, or something, presumably your browser/clipboard/term did something funky when you copied.
Yes, the visualizers are key. My experience is that every team needs approximately one Git guru who can run basic training sessions, dictate the workflow (branching/tagging/etc), and fix things when they go wrong. Otherwise you get stick with a bunch of people memorizing Git commands and creating some unusable history.
And while I say “Git”, it’s really the same situation for any VCS, in my experience. I think the underlying problem that a VCS solves is the truly complicated part here.
> And while I say “Git”, it’s really the same situation for any VCS, in my experience.
Sorry, but no. I have taught CVS, Subversion, and Mercurial to executives, artists and students. They have no problem with the mental model.
With git, people with a Master's in CS get screwed up.
Having "working", "staging" and "repository" concepts is the problem. Maybe "staging" makes Linus' life easier, but unfortunately git escaped to the common people and "staging" makes life miserable for the 99% of normal use cases.
Given the number of times I've had to go in and rescue someone using e.g. SVN or Hg, I can't say I've had the same experience.
The major problem is that as soon as you have a team of people with the same repo checked out, you have as many branches as you have people. These branches may not have explicit representations in the underlying VCS, but they exist just the same.
And so then you're dealing with scary "merge conflicts" for work that people have, from their perspective, already done but can't commit and push out.
Subversion is simple to understand because it is simple, and relatively incapable. If you only use git like you would use Subversion, it's simple too. Subversion is much less easy when you have to do something like merging a long-lived branch.
You conveniently omit the inclusion of mercurial in the list. Mercurial is as powerful as git is--in a few cases, arguably more so (phases make history rewriting safe!)--and yet there is pretty objectively far less confusion for newbies than git has.
There's ample evidence that git is unnecessarily complicated for the DVCS model it uses.
I found that the visualizers made it much more difficult to learn git for me. I couldn't make sense of what they were showing. It was just a bunch of lines of wildly different colors that made no sense. (I think part of it was that in most applications and when drawing things on paper, time goes left to right, but the visualizers always draw them top to bottom.)
> Github, I think, does a disservice by trying to present commits as a linear list - while certainly it's easier to code a linear visualization, it makes people feel like Git is impenetrable magic, when it's anything but.
I feel so alone every time I say this, so thanks.
If you give me half an hour (well, I suck at time estimates... a few hours, maybe) with someone, I can fix their thinking about this tool. But I don't have however many hours with the world.
On Ubuntu the older version of gitg is vety easy to read as well.
I like Sublime Merge but can’t for the life of me visually 7nderstand anything from the way it displays branches. gitg is wayy easier, particularlytbat it doesn’t mix a bunch of unrelated branches chronologically.
Like, i don’t care that there is a stack that branched from here or there, let me just see quickly what THIS branch i’m working on "grows" from.
This is not true. Which version of GitX are you using? There are a number of different forks, and the one I get from “brew cask install rowanj-gitx” works fine on Catalina. It is from 2014, but it’s code-signed and it’s 64-bit.
If you are using the older fork from http://gitx.frim.nl/ then it’s a 32-bit binary from 2009. That version won’t work on current macOS versions, but it will run on my Power Mac.
I see newer engineers struggling to memorize "what Git command corresponds to my current situation" all the time, and they're missing the intuition that it's all a very simple graph under the hood. Github, I think, does a disservice by trying to present commits as a linear list - while certainly it's easier to code a linear visualization, it makes people feel like Git is impenetrable magic, when it's anything but.
(Full disclosure: my love of visualizations of commit graphs may very much be influenced by the game Fringer [1], which was a formative part of my childhood!)
[0] https://rowanj.github.io/gitx/
[1] https://www.youtube.com/watch?v=mAV7IioO_t8