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.
Ask HN: Can we do better than Git for version control?
21–30 of 309 posts
Re: Ask HN: Can we do better than Git for version control?
#22Besides 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.
Re: Ask HN: Can we do better than Git for version control?
#23I 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 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?
#24Re: Ask HN: Can we do better than Git for version control?
#25Re: Ask HN: Can we do better than Git for version control?
#26You 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.
They don't even bother to add directory tracking ;)
Re: Ask HN: Can we do better than Git for version control?
#27If 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* 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?
#29The 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?
#30Of 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…
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.