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

Ask HN: Can we do better than Git for version control?

news.ycombinator.com

Post reply on HN
Print view View original

71–80 of 309 posts

Re: Ask HN: Can we do better than Git for version control?

#71

Post by IshKebab »

zer00eyz wrote: post #57
IshKebab wrote: post #28

Yes. Here are areas where git sucks: * UX, obviously. * Large files (LFS is a not-very-good poorly integrated hack) * Very large projects (big company codebases). Poor support for sparse/partial checkouts, stateful operations (e.g. git status still scans the whole repo every time on Linux), poor & buggy support for submodules. * Conflict resolution. It's about as basic as it can be. E.g. even zdiff3 doesn't give you…

> The diff algorithms are all fast but dumb. Patch based VCS systems (Darcs, Pijul) are apparently better here. Isnt one of git's core features that it can work as a patch based system? It's my understanding (and please correct me if I'm wrong) that Linux patches can come in via mailing list, as a diff. That would make the person committing different from the owner of the change (also reflected in git's design)? Do D…

Got can apply patches, yes. But I mean when it has two commits (which are snapshots, not patches) and it uses a diff algorithm to synthesise a patch between them.

It uses an algorithm which is great from a computer science point of view (low algorithmic complexity, minimal length, etc.) but pretty bad from a semantic point of view (splitting up blocks, etc.).

There are a couple of attempts to improve this (DiffSitter, Difftastic) but they don't integrate with GUIs yet.

Re: Ask HN: Can we do better than Git for version control?

#72

Post by DemocracyFTW2 »

> Or is it a solved problem and Git is the endgame of VCS

I've read so many comments to the effect that "X is a solved problem" when it clearly wasn't that I've come to conclude that the phrase means the opposite of its surface value...

I'm pretty sure that Git is not the end-of-line as far as VCSs go. Whether I will ever change my VCS, again, ever, that is an entirely different question. I've been through so many of them (RCS; a bit of CVS; a bit of Subversion which promised to be CVS-without-the-flaws, which it was not; Mercurial, because hey it was written in Python, so must be good, right? right?; finally Git; and of course the usual `report-v4-revision-good-one.doc` renaming game; plus a plethora of backup solutions, some really bad ones among them)—so many of them I'd be loathe to switch to yet another one, except maybe Fossil, which I almost did.

So yeah, I had totally forgotten about https://fossil-scm.org ; the reason it didn't become my go-to solution is probably mainly the fault of github.com, which I find too good to be ignored, and I don't want an 'impedance mismatch' between my system and their system. But maybe it would be doable and maybe Fossil is good enough to be worth it; at any rate, go read their docs, especially where they compare themselves directly to Git and give lots of good reasons for their way of doing things. This is the same people who are doing SQLite, so I'd say a trustworthy source of reliably top quality software.

Other than that, my personal way of dealing with the complexities of Git is to avoid using parts that I don't need or don't know about well enough (i.e. almost all of it). I use it to check in changes, give one line of comment, and upload to github.com; then of course cloning and updating existing repos as well as setting up a new ones is within my skill set. Branching and merging not so much. So it's like `git` plus `clone`, `add`, `commit`, `push`, that's all; also, I use Sublime Merge for part of these (reviewing changes, adding related changed chunks, commit) which I must recommend for the piece of fine software that it is.

I also at some point toyed with gitless (I think it was called) which promised to be Git, but simpler for the simple things and you can always fall back to Git proper where called for; this I find a good proposition that I like (Markdown: fall back to HTML; CoffeeScript: fall back to JavaScript) but somehow gitless didn't stick with me; I guess that's b/c I've already tempered down my usage of Git to a point near absolute zero, and command line history + Sublime Merge does the rest.

Re: Ask HN: Can we do better than Git for version control?

#73

Post by q0uaur »

zadokshi wrote: post #8
pulse7 wrote: post #6

Of course there is a room for improvement... One of the biggest issues is usability/user experience: pull, fetch, checkout, commit, push, rebase - what is all this and what is the exact meaning? I need simple English terms for my work - like update and save - nothing more. Why do I need to worry about implementation details and terms? If I can not explain it to my wife, then I can not use it for binary documents whic…

To be honest, I can’t even imagine what you imagine “git save” and “git update” would even do in an alternate universe.

when i started out with git i made an alias to immediately do "git add . && git commit -m 'lazy' && git push" to make it easy to always save my work and ensure its on the server too. git pull is easy enough to remember + type, but i could imagine just calling it update

Re: Ask HN: Can we do better than Git for version control?

#74

Post by from-nibly »

retpoline__ wrote: post #14
zadokshi wrote: post #8

Earlier quoted context omitted.

To be honest, I can’t even imagine what you imagine “git save” and “git update” would even do in an alternate universe.

This is funny because in PR oriented development I started treating commits in the same way as "save" in IDE, it's just backup of current state with irrelevant commit message. Everything is described at the end of the work in PR's description and squash merged.

But then you can't use blame to look at the current code state. And it also becomes a nightmare to revert your changes.

Re: Ask HN: Can we do better than Git for version control?

#75

Post by Aachen »

eternityforest wrote: post #61
Aachen wrote: post #52

Earlier quoted context omitted.

> the question is, can we make an alternative to GitHub? I wouldn't be surprised if there are already several better ones, but I've never looked, because I already know Git ¿Que? If you're wondering whether we can make something better than GitHub, there's dozens of git hosting alternatives that you might like better such as Forgejo and GitLab. If you're saying "but I already know git", then there's still dozens of a…

GitHub is the one everyone else uses though, which means you can have everything in one place, so they have the advantage. There are others that are almost as good, I suppose what I should have said is "Can we make something better than GitHub for the hypothetical better non-git VCS", since without that it's hard to imagine using anything but Git.

Pretty sure alternative git services are still larger than alternative source control systems, yet OP is asking about alternatives to git which will be even smaller. The whole point is that the person wants to use something else. If your argument is that Microsoft GitHub is the largest and therefore the best, it's circular reasoning and will forever remain that way.

We should all stay on Facebook also if they're the best because everyone's on Facebook and the network effect has benefits; somehow it seems people have more sense than that and we can actually switch to smaller services which are more aligned with what we want

Re: Ask HN: Can we do better than Git for version control?

#76

Post by happymellon »

zadokshi wrote: post #8
pulse7 wrote: post #6

Of course there is a room for improvement... One of the biggest issues is usability/user experience: pull, fetch, checkout, commit, push, rebase - what is all this and what is the exact meaning? I need simple English terms for my work - like update and save - nothing more. Why do I need to worry about implementation details and terms? If I can not explain it to my wife, then I can not use it for binary documents whic…

To be honest, I can’t even imagine what you imagine “git save” and “git update” would even do in an alternate universe.

I would imagine git save is commit, and update is pull?

I think they just want to replace some of the words with alternatives that they prefer. Because at some point someone is going to winge that update should be syncronise and not pull, and save should be push and therefore git is the worst.

Re: Ask HN: Can we do better than Git for version control?

#77

Post by Apreche »

A lot of people these days have just been thrown into the fire with Git as the first and only VCS they’ve ever seen.

I’m not that old, but I’m old enough to have used RCS, CVS, SVN, then finally Git. I started using Git super early, before GitHub existed. You may not believe me, but Git was the answer to all my prayers. All those previous systems had fundamental architectural flaws that made them a complete nightmare to use on a team for any serious work.

Git has no such problem. There’s nothing it can’t do. Instead, the only limitation is on the user being able to know how to get Git to do what they want it to do. Thankfully, that’s always solvable with a quick read of the documentation or web search.

I understand that people might want to make it easier, since the UI is complex, but that’s never going to work. If you abstract away the complexity of the UI, you will necessarily abstract away the power. If you abstract away the power, you are no longer solving all the problems that Git solved. People just don’t realize what problems are being solved because they never lived through those problems with the previous VCSes.

You know what’s easier than building a new VCS better than Git? You know what’s easier than using a different VCS from the rest of the world? You know what’s easier than designing a miraculous abstraction on top of Git?

Learning Git.

Whatever effort you are putting into seeking or building an alternative, instead put that effort towards becoming a Git expert. It will be a lot less effort with a lot more benefit. Trust me on this. It will be well worth it for your career and for your personal computing life as well.

Re: Ask HN: Can we do better than Git for version control?

#78

Post by fragmede »

Yes we can. The shortcomings of git are that it doesn't handle binary files well, and you can't clone a slice of a repo. the system after git will handle both of those. mono repo or not is not a question with aftergit because you can clone just a subdir and work there, without the overhead of cloning the whole thing, but also without the weight of keeping up with commits happening outside of your directory.

Re: Ask HN: Can we do better than Git for version control?

#79

Post by bryanlarsen »

swah wrote: post #66
rapnie wrote: post #9

Jujutsu version control system looks very promising in the way it brings the best of other DVCS'es together and innovates on various concepts. It has been discussed a number of times on HN before. [0] https://github.com/martinvonz/jj [1] 4 montsh ago, 261 comments https://news.ycombinator.com/item?id=36952796 [2] 2 years ago, 228 comments https://news.ycombinator.com/item?id=30398662

Surprised this is done in Rust. I could never imagine not doing the v1 of something like this in Python or similar, to be able to change things quickly. Maybe the design was very clear on the person's mind.

Rust is a fabulous language for refactoring. Strong types and complete matching make it almost completely impossible to miss a spot when making a change

Re: Ask HN: Can we do better than Git for version control?

#80

Post by bryanlarsen »

Apreche wrote: post #77

A lot of people these days have just been thrown into the fire with Git as the first and only VCS they’ve ever seen. I’m not that old, but I’m old enough to have used RCS, CVS, SVN, then finally Git. I started using Git super early, before GitHub existed. You may not believe me, but Git was the answer to all my prayers. All those previous systems had fundamental architectural flaws that made them a complete nightmare…

The git model has fundamental limitations because it saves snapshots rather than changes, and doesn't capture some metadata changes like renames. A tool like Darcs or one of its spiritual descendants will have fewer merge conflicts than git.

Totally agree on your main point though. The benefits of switching are far lower than the costs.

Post reply on HN