Live data from Hacker News

20 years of Git

blog.gitbutler.com

131–140 of 240 posts

Re: 20 years of Git

#131
post #54

Of all the many source control systems I've used git has the worst usability yet it's my favorite

Why?

Not your parent.

I never understood the "git cli sucks" thing until I used jj. The thing is, git's great, but it was also grown, over time, and that means that there's some amount of incoherence.

Furthermore, it's a leaky abstraction, that is, some commands only make sense if you grok the underlying model. See the perennial complaints about how 'git checkout' does more than one thing. It doesn't. But only if you understand the underlying model. If you think about it from a workflow perspective, it feels inconsistent. Hence why newer commands (like git switch) speak to the workflow, not to the model.

Furthermore, some features just feel tacked on. Take stashing, for example. These are pseudo-commits, that exist outside of your real commit graph. As a feature, it doesn't feel well integrated into the rest of git.

Rebasing is continually re-applying `git am`. This is elegant in a UNIXy way, but is annoying in a usability way. It's slow, because it goes through the filesystem to do its job. It forces you to deal with conflicts right away, because git has no way of modelling conflicts in its data model.

Basically, git's underlying model is great, but not perfect, and its CLI was grown, not designed. As such, it has weird rough edges. But that doesn't mean it's a bad tool. It's a pretty darn good one. But you can say that it is while acknowledging that it does have shortcomings.

Re: 20 years of Git

#132
post #65

There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be th…

I am rooting for pijul.

[deleted]

Re: 20 years of Git

#133
post #65

There’s something that bothers me about these sorts of recollections that make git seem… inevitable. There’s this whole creation myth of how Git came to be that kind of paints Linus as some prophet reading from golden tablets written by the CS gods themselves. Granted, this particular narrative in the blog post does humanise a bit more, remembering the stumbling steps, how Linus never intended for git itself to be th…

The article is written by a co-founder of github and not Linus Torvalds.

git is just a tool to do stuff. It's name (chosen by that Finnish bloke) is remarkably apt - its for gits!

It's not Mecurial, nor github, nor is it anything else. Its git.

It wasn't invented for you or you or even you. It was a hack to do a job: sort out control of the Linux kernel source when Bit Keeper went off the rails as far as the Linux kernel devs were concerned.

It seems to have worked out rather well.

Re: 20 years of Git

#134

When are we moving to SHA256? Some code bases must be getting massive by now sfter 20 years,

Are you worried about hash collisions from different objects? The probability of a collision of N distinct objects with SHA-1 is (N choose 2) * 1 / 2^161. For a trillion objects the probability is about 1.7 x 10^-25. I think we can safely write code without collisions until the sun goes super novae.

[deleted]

Re: 20 years of Git

#135
post #51

Earlier quoted context omitted.

Mostly because it is jarring for users that want to interact with tools which require these footers -- and the setups to apply them, like Gerrit's change-id script -- are often annoying, for example supporting Windows users but without needing stuff like bash. Now, I wrote the prototype integration between Gerrit and Jujutsu (which is not mainline, but people use it) and it applies Change-Id trailers automatically to…

Thanks for the explanation! While you're around, do you know why Jujutsu created its own change-id format (the reverse hex), rather than use hashes (like Git & Gerrit)?

[deleted]

Re: 20 years of Git

#137

Earlier quoted context omitted.

For me it won (10+ years ago) because for some reason git (a deeply linux oriented software) had better Windows support than Mercurial (that boasted about Windows support). You could even add files with names in various writing systems to git. I am not sure that Mercurial can do that even now.

Huh, that's not my recollection. Mercurial on windows was "download tortoisehg, use it", whereas git didn't have a good GUI and was full of footguns about line endings and case-insensitivity of branch names and the like. Nowadays I use sublime merge on Windows and Linux alike and it's fine. Which solves the GUI issue, though the line ending issue is the same as it's always been (it's fine if you remember to just set…

For what it's worth, I've encountered filenames which cannot be decoded as utf-8.

Re: 20 years of Git

#138

Earlier quoted context omitted.

I wonder this too. My guess is that he did not like "heavyweight" branching and the lack of cherry-pick/rebase. At any rate that is why I didn't like it back then. Sun Microsystems (RIP) back then went with Mercurial instead of Git mainly because Mercurial had better support for file renames than Git did, but at Sun we used a rebase workflow with Mercurial even though Mercurial didn't have a rebase command. Sun had b…

Ironically hg now has better rebasing than git e.g. the evolve extension

Ah, right, at Sun we used MQ. But anyways, just glancing at the hg evolve docs I'm unconvinced. And anyways, it's an "extension". Mercurial fought rebase for a long time, and they did dumb things like "rebase is non-interactive, and histedit is for when you want to edit the history".

And that is partly why Mercurial lost. They insisted on being opinionated about workflows being merge-based. Git is not opinionated. Git lets you use merge workflows if you like that, and rebase workflows if you like that, and none of this judgment about devs editing local history -- how dare the VCS tell me what to do with my local history?!

Re: 20 years of Git

#139
post #63

Earlier quoted context omitted.

Not parent, but for me it was a couple hours of reading (jj docs and steve's tutorial), another couple hours playing around with a test repo, then a couple weeks using it in place of git on actual projects where I was a bit slower. After that it's been all net positive. Been using it on top of git, collaborating with people via Github repos for ~11 mos now. I'm more efficient than I was in git, and it's a smoother ex…

> Every once and a while… The expression is “every once in a while” :).

Oops :)

Re: 20 years of Git

#140

Earlier quoted context omitted.

In my 25ish years I’d professional dev, I’ve used git for about 15 of them. I’ve never used Perforce and never even heard of Sapling. It’s very likely that most if not all of the software stack you’re using to post your comment is managed with git.

I am keenly aware of how common Git is. A whole generation of programmers have only ever known Git and GitHub. They assume that since it is the standard it must be good. This is a fallacy. Bad things can become popular and become entrenched even when better things exist. Replacing Git today would require something not just a little better but radically better. Git was always worse than Mercurial. It won because of Gi…

So none of the stuff you’re using qualifies as “adult projects”?

I don’t object to saying we can do better than git. But saying git “is for hobby side projects” is ridiculous. It’s fine for serious projects.

Post reply on HN