Hacker News Reader

> WTF is "detached HEAD"? I've looked it up dozens of times, and as soon as I get past whatever I'm working on, I forget what it means. I don't know what the reflog is, other than that it has to do with some dark internals.

I could answer, but I don't think you're actually asking for someone to explain it to you.

I did want to offer a different opinion though. I like detached heads, they are unnamed branches, the first thing I do when working on something new is make a detached head and get to work, making commits, etc, if I decide the work is worth keeping, then I will name the branch. As some smart people have said, naming things is hard, I don't want to name a branch before I'm sure what it is or that I'm going to keep it. Having a bunch of commits that are not part of a branch might sound risky, but not if you understand that commits are never deleted (unless there 90 days old or more) and the reflog and other tools allow you to find commits you thought might be lost. Git does not lose commits, not ever.

Naming is only hard if the names are permanent (cough fossil & hg)

But git names are not permanent, so just use whatever helps you remember: "just-ate-tuna-sandwich", "fifth-time-is-a-charm", "john-is-late", "idea-from-restroom", even "temp123"...

You can always rename to something that makes sense later.

Yup, my names break up into two categories, each with a namespace: `wip/` and `deadend/`. deadend is my personal favorite. Every time I write some code that turns out to not work, instead of spamming undo until I get to a known good state, I do:

    git commit -am “Dead-end: I tried doing X but that didn’t work out”
    git branch deadend/tried-doing-x
    git reset —-hard HEAD^

I like this because, fully half the time I end up needing to draw some elements from that dead-end if it turns out later to have seeds of the right approach in it.

`git branch <something-temporary>` is an absolutely fantastic workflow IMO, combined with committing early-and-often, it helps me decide on logical names for various snapshots of where I was when trying to solve a problem. When I hear people say “squashing is wrong” I can never understand what they’re on about: being able to make temporary semi-meaningful commits and branches on your way to the right answer to a problem, is an absolute godsend.

Yeah, not really looking for an answer. I have a decent idea, and I could guess. It's one of those things where when I find myself in that state, it means I messed something up. I google, read a few sentences, remember what it means and how to get to the state I want to be, and then move on with my life without committing the details to memory. It's one example of the confusing scenarios I find myself in with Git with more frequency than seems necessary. I'd rather debug a Kubernetes cluster.

Git does make a detached head sound like something is broken, but it's really just a nameless branch. Nothing broken about it. Any commits might become hidden, as all commits not in a branch are, but that's only after you move off the headless branch and git warns loudly about this.

I just tested to see what happens if you don't name a branch before leaving it. Surprisingly, despite all that scary looking text about detached head, if you switch over to another branch git will print out a message that you're leaving commits on an unnamed branch as well as instructions on how to get back and name it later (and of course the commit hash can also be recovered from the reflog).

So yeah not only is the detached head state not a broken state, it's not even really a scary state to be in.

For someone who understands git, it certainly is not. But if you are not aware of how git works, committing things when HEAD is detached could to confusion in the best case, and lost commits in the worst.

Naming is trivial, _1, _2 , etc, exist.

Good naming is hard, but you don't need those for your use case of potentially discardable work

I just use stacked branches and work out of the top branch. When changes are solid -ish I move down a level in the stack and cherry pick isolated changes into small/focused commits. Then I put the entire stack in review with a doubly linked list references so the reviwer can walk up and down the stack to see the corpus of changes.

That way a 1000 line pr consisting of 25 commits can be landed as 5 dependant prs with a much more focused review.

Why many developers are struggling is beyond me, and so much git-hate, too. It is a powerful tool, but you can get started and a long time (or forever) around with few commands to accomplish your companies workflow - takes half an hour to learn these and put them in your notebook. If you struggle with git, how do you do with your programming language, IDE, debugger? All are vastly more complex.

Imo it is some internal objection (due to hate? laziness?) to deal with it.

Yes, the UI is not intuitive in all parts and partly ugly or from some viewpoints inconsistent, but that lately improved much. Nevertheless, complex is different. Much more effort went into mastering chosen shell, much more unintuitive is the IDE I have to use.. but those are tools, and that's my job.

> WTF is "detached HEAD"? I've looked it up dozens of times, and as soon as I get past whatever I'm working on, I forget what it means.

Don't wanna be mean, but again I wonder how you learn and handle e.g. complex data structures (vs that super simple thing..) or other hard problems in whatever you do.

> And on any team I've ever worked on, the branch history is a nightmare to look at.

Because teams have many people that don't care. I like git, shuffle commits around, rebase easily, conflicts are easy to resolve (there are merge tools that exist to help on top?) or would be hard with any other tool the same? (need to try jj). At least I have seen same shit happen with cvs, svn and also the short time I used hg - people are always at fight with their version control, I don't know why. I'm glad if there is a new tool that finally solves this, buut, I doubt it ;) Let's see.

> I want a dead simple VCS for small project use that doesn't come with so many footguns. I know simpler VCS exists, but without wide

Sorry, but lame excuse, just chose and try one and see, don't spread that much git-hate if you have not even tried, and mastered, another one? (And here you are with jj!)

OP said 'I can't stand Git.' You seem to be obsessed with labeling that as 'hate' (3 times) and belittling people you think are not as smart as you.

I'd bet within the past week you were swearing at git. :-)

I’m a native english speaker and I view “hate” and “can’t stand” as being synonyms. I can’t for the life of me draw a distinction between what either phrase means.

FWIW I thought "hate" and wrote "can't stand" because I intentionally wanted to tone it down just a little bit. "Hate" is a pretty biting word and I'm trying to use it less hyperbolically. The distinction is more one of politeness than anything in this case, so I agree with you.

Good for you. The person I was replying to could stand to learn from your example. Where by 'could stand to' means would love to. :-)

I'm frankly embarrassed at my lack of Git mastery. I'm sure I could master it. And considering it's a tool that's integral to my daily work, it's kind of ridiculous that I'm not more comfortable with it.

I've written parsers and compilers, worked on image processing software for the NASA Mars rovers, managed global Kubernetes deployments for Fortune 500 companies, wrote trading desk software used on the NYSE trading floor, etc. Point being, I've worked on some seriously complex software. I'm 100% sure I could write Git itself without any trouble whatsoever (assuming I learned how it worked first).

I find Git to be unintuitive and overly-complex, and to use terminology that isn't obvious. You're probably right about it being an internal objection, but I assure you it's not due to laziness or an inability to deal with complexity. I'm not planning to use jj, because it's just Git with more complexity layered on top, despite their claims to the contrary.

Despite my dislike of Git, I'm still the go-to person for Git issues on the teams I manage. I can fix problems that arise and help others do things right. I still don't like it, and for whatever reason, the edge case scenarios don't stick in my memory.

i wonder where that comes from. i don't even have a fraction of the experience you have, yet i seem to be just fine with git. not an expert, but not having any trouble with it either, and also the go-to person for git pretty much anywhere i work. and i do like it!

is it my age? (i learned working with computers in the late 80s.)

the fact that i first had to work with CVS and subversion?

that i was an early adopter? (i was the first to use git at my job at the time, thanks to its good subversion integration)

have i just not seen how much better git could be? (am i happy with git out of lack of experience with better tools?)

or am i just different? (i seem to have no problem with weird programming languages or frameworks either (although there was this one perl job where i did struggle and ultimately had to give up because i had no help))

To emphasize just one thing in Git that is a source of constant user woes: if you're doing a rebase merge, --ours and --theirs are reversed. This is unintuitive without a deeper understanding of how rebase works, and rebase itself is a concept that is confusing to most users. Conflicts are never easy to resolve under the best circumstances. You shouldn't have to flip everything around just because you're doing a rebase merge instead of a regular merge. I can't tell you how many times I've had to help people with that. Maybe you think that makes total sense and is obvious, but the majority of devs I've worked with struggle with it. The fact that there are different types of merges is already confusing enough. Even the > and < symbols are reversed during a rebase merge, such that even if you know, your brain is twisting itself in knots because of the conflicting visual indicator.

> I don't know what the reflog is, other than that it has to do with some dark internals.

I think this illustrates a bit the tragedy of git's (lack of) UI. Since the reflog is a feature, not an exposed hidden internal. It's simply a log of what a reference, say HEAD, or a branch, has pointed at. It's meant to help you figure out what happened, or get back to a place you lost through some other operation.

Doesn't it strike you as odd that devs get "lost" often enough to need this "feature"?

I've used CVS, SVN, hg, bzr, and git. Why does git stand alone as the only VCS where devs need so many foot bandages?

Not really. I think of it as git’s undo button. I don’t criticize my word processor for being so complex that it needs an undo button.

That analogy is verging on dishonest. A word processor’s undo button is typically used in service of the operator’s thought process, as it pertains to their actual output, not how they’re using the word processor. The analogue to this is git itself.

I said typically though. We all know the “you move an image in Word and your layout completely changes” meme. Sometimes someone wants to undo something because the tool didn’t do what they intended. Even though I have no empirical basis beyond my no experience, I am incredibly confident that the typical use of Undo in a word processor is because the operator has changed their mind about what they want their output to be, rather than because they had already concluded what they want the end result to be and they just can’t get the software to do it. I have to imagine that you agree with this.

So yes, be thankful that git has reflog. All other things equal, git with reflog is better than git without. I don’t see how your analogy invalidates or refutes the the critique that typical use of git’s reflog is as a result of the operator not knowing how to use git. And to simply say “you’re holding it wrong”, when ‘holding’ git routinely involves standing due East at the next full moon, is absurd.

A person who isn’t “good at” word processors will use it both when they change their mind and when the program doesn’t do what they want (e.g. I didn’t realize that I had a text selection before I started typing and now my selected text is deleted). It’s the same with git, and now we are just arguing about what’s “typical”. An example of when I change my mind about what I told the program to do, maybe when rebasing I decide my merge resolution wasn’t actually what I wanted. That is certainly in the “user changed their mind” class of error.

I’m not saying git has a great user interface that users intuitively grok and rarely make mistakes in. But I am saying that having an undo button is not an admission of that, either.

The point is that other tools achieve the same with less complexity in the users mental model.

If you use the undo button because your word processor doesn't do what you want a lot, maybe look for a word processor that's better designed.

if you are satisfied with CVS/SVN version - any commit is final and there is no way to undo or modify them - then you don't need reflog. If you mess up, you just say: "oh well this sucks" and leave commit in place. This is what I was doing back when I used SVN and CVS.

hg has similar thing but it's different for each command. For example to undo "hg strip" you manually dig into .hg/strip-backups directory.. I never understand why people call it more intuitive.

Can't tell you anything about bzr, never used it.

I haven't used reflog in probably 2-3 months but it's just a small thing to know it doesn't hurt.

Because we insist on telling people to Rebase as part of the standard workflow, which is just a huge footgun for people who dont understand what they are doing.

Maybe version control is actually a hard problem, and there are no simple solutions. And I'm sorry to pile on, but if you haven't learned more than the basics in 20 years, have you considered sitting down and doing some focused git work? Maybe play with libgit2 and learn the internals.

> I still can't accomplish anything more than the most basic things...

A few hours on https://learngitbranching.js.org/ and it'll make sense to you.

Yeah I've just given up on git. There should not be as many interfaces and experts on such a little tool. Now I only use commits and reverts. Not even branches. And all 100% with a GUI. Otherwise it takes up way too much of your attention

But how often do you really need more than the basics? I think you're probably doing something wrong if you constantly need to look up docs on it. If you're not constantly doing that, it sounds pretty good. Takes care of the basics and the more complicated features stay out of the way.

> So I clicked on this link with the hope that it might be a kinder, simpler VCS.

Last thing we want is a kinder, simpler, dumber VCS replacing git, like microframeworks which hardly have HTTP routing and middleware replaced full featured frameworks.

The very comment you’re cherry-picking from right now doesn’t pose a complete git replacement. It’s posing a replacement for git in certain situations.

I dunno why you got downvoted to dead state. I vouched your comment because you're not wrong.