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.

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

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

looking forward to

'merge patch graggle revert --flatten'

posts littering stack overflow in the future

  git log —-graph —-oneline —-decorate

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

  # —-all to include all branches

    git log --graph --oneline --decorate

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.

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.

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.

There's ample evidence that git is unnecessarily complicated for the DVCS model it uses.

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.

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.

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

https://github.com/soramimi/Guitar

Nice, simple and multi-platform.

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

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

Nice, simple and multi-platform.

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.

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