Hacker News Reader

Comment by smabie | Hacker News Reader

It's not that it's hard or complex, it's that I really don't care about it and am not at all interested in learning. It's a weak attitude, I know, but I just can't help it.

So like most other developers, I go about my day totally not understanding git at all and when something weird happens, I talk to that co-worker know understands get (there's always at least one such psychopath on each dev team in existence) and ask him to fix it. He invariably talks about how easy and elegant git is and then finally gets around to giving me a couple commands with non-sensical names and options that fix the problem.

I don't care, and I'm okay not caring. Not learning git might even give me extra time to learn about these magical computer algorithms I've heard so much about.

View on HN

> there's always at least one such psychopath on each dev team in existence

I'm that psycopath :D

> I don't care, and I'm okay not caring. Not learning git might even give me extra time to learn about these magical computer algorithms I've heard so much about.

I'm fine with this actually. If you don't care, and don't want to. That's actually totally fine. I personally will look at you a bit strange. But when it comes down to it. You should only care about what you want to. But please, for my continued (admittedly borderline) sanity. Don't try to convince others that it's too hard to learn, and/or that they shouldn't try. I want to work with people who are curious, people who want to learn how cool things work. But there's a trend in software engineering, that parts of it are too hard, and that it's a waste of time to learn them. That's a scary thought to me; imagine the next generation of software devs, all convinced that they can't understand something, or that it would be a waste of their time to try?

I see it like learning a build system: ultimately a pointless piece of trivia that isn't very interesting or worthwhile. This is in contrast to math or CS, which is generalizable and timeless.

But you're right, we should all understand this stuff. And if it wasn't for that one magic coworker (you're really taking one for the team), I probably would.

Git is a little bit different. It is a really good implementation of the 'history is immutable' philosophy of programming.

Learning the implementation details and reading the mystifying documentation to learn what something is called can be a bit wasteful but understanding the git model is very worthwhile. It is interesting to see how it handles the pragmatic issues of fixing the situation up when the history becomes snarled.

Learning git will make some not insignificant number of people better at concurrent programming. Most build systems don't do that..

It's not that good. For one, rebase mutates history. Also the ui is confusing and inconsistent even if the data model is pure and beautiful.

Rebase does not mutate. It creates new commits and updates the rebased branch to point at them. The original commits still exist (even if no other branch points at them).

Git commits are never mutated. They are referred to by a hash of their content after all.

Rebase sure seems like it mutates.

What's the UI for getting at those old commits? Is it possible to get a true chronological log from them? Do they stay around forever or do they get garbage collected eventually?

Good:

  git log --all --graph --oneline --reflog

Better:

  git config --global alias.lg "log --date=format-local:'%Y-%m-%d %H:%M:%S' --pretty=format:'%cd %<(20,trunc)%an %C(auto)%h%Creset%C(auto)%d%Creset %s'"

  git lg --all --graph --reflog

> Is it possible to get a true chronological log from them?

The output of git log with --graph is not chronological, because it does a topological traversal of the commit graph.

> Do they stay around forever or do they get garbage collected eventually?

They get garbage collected eventually. As a rule you should not assume dangling commits are safe. If you need to keep one, assign a trivial branch name to it.

> What's the UI for getting at those old commits?

The same as any other commit. You can check them out by referring to their hash, by referring to any tags that point to them, or any branch that points at them.

The other reply gives options assuming the commits have been orphaned (no tags or branches point at them).

As far as I know, commits that were once ancestors of a branch can sometimes no longer be ancestors of that branch. If that's not a mutation, then the word is not as useful as I thought.

Branches are just pointers into a graph of commits. The graph cannot be mutated (it can be pruned by garbage collection but that does never happen related to an oh shit event, it takes weeks even in a heavily modified repo). The pointers can be modified to point anywhere else in the graph, which makes things look mutated without being mutated. Using reflog you can get your back to where your pointers pointed to at any earlier point of time.

I'd say it's a pretty standard use of the word. Branches are analogous to pointers. If a program changes where the pointer points, it has not mutated any values, besides the pointer itself.

(Obviously the branch/pointer itself is mutable.)

> Git is a little bit different. It is a really good implementation of the 'history is immutable' philosophy of programming.

I beg to differ. Mercurial is all about immutable history. Git is explicitly designed to mutate history (that's what rebase does) in the demented (IMHO) pursuit of a linear change log.

I'm that psychopath too, but only because I use git 1000 times a day. It's not by choice. Git has a horrendously shitty UI and it's quite hard to learn because the UI is inconsistent, patternless, and uses a different vocabulary than mainstream computer science (a staging area is called an "index", revert is called "reset" and "revert" means something completely different, "fast-forward" is a term from the world of linear tape recorders which is meaningless when applied to graphs, but git uses it for graphs anyway, etc).

Git is worth learning but it's about 10x harder to learn than it would have been had its designer known anything about human interface principles. And its manual is useless because that same designer wrote the manual too.

Git would be completely unlearnable without Google and Stack Overflow, but since those things exist, it's worth learning.

I'd wager a lot of developers, good ones, share your sentiments. Git is a well designed, dependable SCM, there is no question. But its command line UI is awful, far too close to the metal. I'm not at all surprised though, it's a UNIX cultural thing -- ignore the 80/20 rule and use the command line for everything. Compare installing anything on Linux vs. Windows. It's ridiculous.

I will never understand this. A couple of hours investment now and you've saved yourself a lifetime of stress and confusion. There aren't many tools that I'm sure are going to stick around for the long-haul, but git is one of them.

Everything about git makes sense except the syntax and the fact it does not compose.

Reply on news.ycombinator.com