Live data from Hacker News

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

news.ycombinator.com

21–30 of 309 posts

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

#21

Besides the frontend problems with git that everybody talks about, the backend could be improved. It's now line-oriented. It would be more useful if it knew about the semantics of the language you were writing so it could show you semantic differences. That might also provide a mode for binary files which git doesn't handle very well now.

Actually, it’s not the backend which is line oriented, it’s the front end. The backend doesn’t dissect files, it stores the entire new file when even one line is changed and relies on object compression to find the similarity in the rest.

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

#22

Besides the frontend problems with git that everybody talks about, the backend could be improved. It's now line-oriented. It would be more useful if it knew about the semantics of the language you were writing so it could show you semantic differences. That might also provide a mode for binary files which git doesn't handle very well now.

Before we can get a vcs that understand semantic diffs, we need a way to communicate semantic diffs. That way each file type can have its own “semantic differ”. Similar to how language servers help abstract away the differences for IDEs

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

#23
post #15

I am not sure if we will ever be able to replace git with anything else. It is so ubiquitous and just "good enough" for most developers, that the pain of switching to a completely new system would far outweight the benefits. Therefore the only solution that I see is a versioning system that is fully backward compatible with git, maybe just a better API layer on top of git. Facebook tried something similar with Saplin…

> It is so ubiquitous

It wasn't until 2011 that Subversion dropped below 50% market share in the Eclipse Community Survey. Something new and shiny will come along and replace git.

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

#26
post #18

You could probably do better, yes. But if someone is to do better, I'd hope they actually learn git first. A lot of alternative tools come up because of people writing them being unwilling to learn git. There are a handful of concepts and a few handfuls of commands and thats it. And once someone learns git throroughly, they usually come to see that it is actually good enough, and dont bother making something new.

> and dont bother making something new.

They don't even bother to add directory tracking ;)

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

#27
An obvious area for improvement would be semantic version control.

If the VCS would have an understanding of not only what has changed but also how this affects the code, it could deduce a lot if interesting facts about commit blocks.

Like ignoring simple refactorings (e.g. renamings), reducing merge conflicts, etc.

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

#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 quite enough information to resolve some conflicts (you want the diff for the change that introduced the conflict). The diff algorithms are all fast but dumb. Patch based VCS systems (Darcs, Pijul) are apparently better here.

IMO the most interesting projects that are trying to solve any of these (but not all of them sadly) are Jujitsu and Pijul.

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

#29
It would be hard to get past the network effects. Just like how we are stuck with SMTP, JavaScript, PDF, HTML, etc.

The only way I could see it changing is if we have a complete paradigm shift. This is what happened when we went from SVN to Git (centralised to distributed).

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

#30
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…

Then you might be better off with something like Subversion indeed.

Git is distributed, and that means you can't get away from push, pull and fetch, however you name them.

If want you want is a way to avoid making "New New Presentation FINAL 2", then pretty much all features of most source control systems are superfluous.

To me that doesn't mean Git needs fixing, it means it's definitely not the right tool for your job.

Post reply on HN