Hacker News Reader

> 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.

> “take this commit and move it here”

Isn't that just `git cherry-pick $COMMITID`?

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.

looking forward to

'merge patch graggle revert --flatten'

posts littering stack overflow in the future

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.

Have you tried the gitless porcelain?

I have not, although I took a look at some point. I really like staging areas :(

Another quick visualization method built into Git:

  git log —-graph —-oneline —-decorate

  # —-graph for the visualization
  # —-oneline for compact commits
  # —-decorate for tag and branch refs

You can also add:

  # —-all to include all branches

I typically add aliases to ~/.gitconfig to use these options by default.

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.

Should be:

    git log --graph --oneline --decorate

Thanks for correcting my error. Stupid “smart” dashes on my phone.

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.

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.

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.

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.

> I absolutely love, and recommend to any new team members, GitX and other similar Git visualizers.

Is there a GUI for git blameall or similar functionality with clickable commits? http://1dan.org/git-blameall/

You have this in vscode I think...

I'd rather recommend Guitar.

https://github.com/soramimi/Guitar

Nice, simple and multi-platform.

Does anyone know a good visualizer for Linux? I find that half the time something goes wrong it's because I don't know the state of the graph.

gitk (comes with Git, part of the Git distribution, your OS packager may have split it out into some package like git-x11)

magit in emacs does a fairly good job,

    git --log --decorate --graph --all

I use all the time (aliased everything except --all as gl)

Also, tig is a nice standalone implementation of a magit like tool.

https://github.com/soramimi/Guitar

Nice, simple and multi-platform.

Gitg. Similar to gitk but with a nicer GTK GUI.

GitAhead works for me

Just an FYI that GitX won't work on an up to date Mac

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.

Yep, rowanj is the one that is up to date, but to be fair it is not the first result on Google.

Here's the fork which I use:

https://rowanj.github.io/gitx/ (`brew cask install rowanj-gitx`)

The upstream also has some signs of life but I don't believe it has a stable release yet:

https://github.com/gitx/gitx