Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Oh Shit, Git?

ohshitgit.com

Post reply on HN
Print view View original

211–220 of 275 posts

Re: Oh Shit, Git?

#211

Post by Certhas »

seba_dos1 wrote: post #196
fragmede wrote: post #115

Earlier quoted context omitted.

This works if the branch exists or creates it if it doesn't exist, but not if it's checked out. git branch -f branch_name commit if it's checked out: git reset --hard commit

> but not if it's checked out ...and for a good reason that should be apparent to anyone who understands git's model (HEAD points to a ref in this case, so if you suddenly change what that ref points to without updating the working tree you create an inconsistency). You can do that manually of course (with `git update-ref` or even a text editor), but then you get to clean up the mess yourself.

To me that looks like git is leaking implementation details left and right.

So much for "a branch is simply a pointer to a commit"...

Re: Oh Shit, Git?

#212

Post by Certhas »

seba_dos1 wrote: post #202
thfuran wrote: post #198

Earlier quoted context omitted.

Couldn't head just detach without any consistency issue?

Theoretically it could, but that would be a rather surprising side effect. You could also check the new revision out and leave HEAD intact. Which one of those outcomes you would expect and why? "error: ref in use by higher layers" makes much more sense to me in this case.

If you buy the "git is just a tree of commits and pointers" mental model it's absolutely not a surprising side effect but would be the logical thing to expect. I moved a pointer to a commit around, why would that change where HEAD is pointed.

Turns out it's a tree of commits and pointers to within that tree and a master pointer that come in two versions: pointing towards the pointers or pointing towards the tree. And pointers behave very differently when the master pointer is pointing to them...

Elegant. Simple. :P

Re: Oh Shit, Git?

#213

Post by Rexxar »

WorldMaker wrote: post #203
zahlman wrote: post #184

Earlier quoted context omitted.

>Starting a new repo in SVN is find a server somewhere, if doesn't have SVN install SVN, if it does have SVN deal with whatever politics runs its trunk to find space/define a branch structure for you, and so forth. Many years ago, SVN worked fine for me for single-user projects. I just made my own desktop be the server. But I wasn't publishing my code back then (it's not as if I would have have any effective way to t…

Around the period I might have adopted SVN I recall it was a huge pain, if not impossible, to install on a Windows desktop; I tried multiple times, failed at each attempt, and eventually gave up. I was also in some labs at the time where we weren't allowed RDP to personal machines or services, or the lab machines just weren't great at it, or both (depending on the exact type of lab class and how worried the professor…

You can create a repo in a directory and use the local path in svn url without using any service or server process since the beginning of SVN.

You can even do it on shared directory for a small team even it's not recommended if there is a lot of concurrent users.

Re: Oh Shit, Git?

#214

Post by guenthert »

paulddraper wrote: post #205
dgfitz wrote: post #144

I’m pumped a search for hg+mercurial had hits in this thread. I am and will continue to be completely blown that hg lost the dvcs wars. It’s a better tool.

It's the slower tool.

That was relevant to Linus in the early 2000s, but then, we didn't have NVMe SSDs.

Re: Oh Shit, Git?

#216

Post by guenthert »

kstrauser wrote: post #45
jazzyjackson wrote: post #32

Earlier quoted context omitted.

"bro", "bruh", it's more of an exclamation of surprise than a title conferred to the person being addressed, but even then, I don't know, people call folks "auntie" and "uncle" who aren't actually their auntie and uncle. language is flexible. it may reference the kind of fraternity between brothers but that feeling is not limited to the male sex.

Can confirm. It sounds so weird to me, but I hear my kids and their friends call each other "bro" or "bruh" all the time, regardless of gender.

Isn't this like 'guys' including gals a generation earlier?

Re: Oh Shit, Git?

#217

Post by OkayPhysicist »

paulddraper wrote: post #204
SebastianKra wrote: post #46

We should start recommending UIs as the default way to learn Git. It would solve a third of these problems and another third wouldn't even come up. If you later decide that the CLI is faster, go ahead. But first, people need to see visually how they can interact with the tree. I like fork.dev, but most clients are pretty similar at this point.

What the average amount of time until something goes wrong that can't be fixed in the UI?

In more than one team I've been on over the years, I was the only person with a deep understanding of Git. What I've found as a result of being the "oh shit git" guy is that

1) all UIs are completely missing at least some of Git CLI's functionality (shoutout to git's most neglected feature, git notes)

2) all UIs have at least a couple git features so tucked away that you'll only find them if you know to look for them (git checkout -- path > temp_file is a common culprit here, but I've seen UIs that hide git ammend)

3) the average time for a UI-exclusive user to need my help for one of those two reasons was about a month.

Re: Oh Shit, Git?

#218

Post by jonasced »

jimbokun wrote: post #58
lalaithion wrote: post #29

Earlier quoted context omitted.

The disconnect between git's beautiful internal model of blobs, a tree of commits, and pointers to commits, and the command line interface is so wild. All of these recipes are unintuitive even if you have a firm grasp of git's model; you also need to know the quirks of the commands! To just look at the first one... wouldn't it be more intuitive for the command line interface to be: # this command exists already; $ gi…

Are there alternative git command lines that keep the beautiful internals, but implement a more elegant and intuitive set of commands to manage it?

Lazygit has a terminal UI but might otherwise be what you're looking for: https://github.com/jesseduffield/lazygit

Re: Oh Shit, Git?

#219

Post by zahlman »

WorldMaker wrote: post #203
zahlman wrote: post #184

Earlier quoted context omitted.

>Starting a new repo in SVN is find a server somewhere, if doesn't have SVN install SVN, if it does have SVN deal with whatever politics runs its trunk to find space/define a branch structure for you, and so forth. Many years ago, SVN worked fine for me for single-user projects. I just made my own desktop be the server. But I wasn't publishing my code back then (it's not as if I would have have any effective way to t…

Around the period I might have adopted SVN I recall it was a huge pain, if not impossible, to install on a Windows desktop; I tried multiple times, failed at each attempt, and eventually gave up. I was also in some labs at the time where we weren't allowed RDP to personal machines or services, or the lab machines just weren't great at it, or both (depending on the exact type of lab class and how worried the professor…

I just used the TortoiseSVN installer on a couple different machines and I recall it being perfectly smooth each time.

Re: Oh Shit, Git?

#220

Post by hiAndrewQuinn »

jimbob45 wrote: post #97
phtrivier wrote: post #89

This will feel very weird in April 2025, when we celebrate the 20th anniversary of git. I was there. And at some point I wondered if I should learn git, darcs, or bazaar, to replace SVN or CVS. Or did I try mercurial too ? I wonder if the "GitHub" effect has basically killed the need for a newcomer in the space of VCS. Maybe at some point, the yak is shaved enough ?

SVN has always worked for me. You don’t have to “teach” people SVN because it’s intuitive and works just fine for the 99% case. I wish we would all stop larping as 1337 hackerz and just admit that git is overkill for the vast majority of people.

Clearly you have never needed code search across 50+ SVN repositories before, then. ;)

No, but seriously, I wrote https://andrew-quinn.me/reposurgeon for a reason. While I actually see some big benefits to SVN over git for areas with large binary assets like game development, the tool is just so ancient these days that it's just easier for me to convert SVN repos to git repos and then use those to figure out what I actually need to do. It feels a lot like working with Laplace transforms, translating and un-translating between two not quite equal ways of measuring reality.

That's not even considering that the kinds of companies still using SVN in 2025 tend to have a lot of code to wade through. Serious selection effects in play there -- mostly for good, to be clear.

Post reply on HN