11–20 of 430 posts
- A client side virtual file system (FUSE), so that you can work with large repos that exceed the size of your own system. Version control systems like Piper (Google internal) and Eden (Facebook), GitVFS (Microsoft) already do this, but adoption is marginal.
> I saw the pain points of git What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics, so I’m curious
- Git is slow on large repos, even on an SSD.
- Git has trouble with large objects; git-annex and git-lfs sort of help, but are bolted on, not integral.
- Git's submodules are unergonomic at best.
- Git's CLI is a mess.
Deeper:
- Git has no idea of a conflict as a first-class object; hence merges and rebases with the user fixing the same conflicts multiple times (and `git rerere`). Compare this to Pijul.
- Git is line-oriented and has no notion of semantic diffs and semantic merges. This makes it a raw tool when working with, ironically, source code.
Don't get me wrong: the data structures and ideas on which git is based are beautiful and reliable. But something (even) better can be built on these ideas.
You better get it right, or otherwise you get to nuke the whole repository.
Git annex functionality built in = gg every other source control system.
> I saw the pain points of git What are these? Asking for real: it’s the second time I read a similar sentence on HN this week, without finding any specifics, so I’m curious
I’m not qualified to go into specifics but I hate it. All version control needs to do is pull, push and branch. Version on branch is newer? You need to pull down before you can check in. Instead what we get is over complicated nonsense with commits and stashes, rebases and heads, reparenting etc. I get it you don’t want to store your code on your local machine but that’s what backups are for, that’s not what the vers…
You can choose which one to use in your project, and someone could enforce or write a wrapper if they wanted to to enforce/encourage a certain method.
Learning one of the above methods, especially stashing and/or pull conflicts, isn’t that difficult or hard to grasp. Git even recommends this if you try to push to a more up to date upstream.
> Semantic diff – Can we figure out how to use version control to have more context-aware merges? Can you believe that we still rely on a text diffing algorithm from 1976 (and its shortcomings)? Git still has trouble with file renaming. GitHub Copilot, but for merge conflicts? Semantic diff has been tried before, but language-specific implementations will likely never work. in case anyone missed it: https://github.co…
To me this looks like integrating it with tools of actual conflict resolution during merges will be a bit harder than one would like. I'd be glad to be wrong.
- A client side virtual file system (FUSE), so that you can work with large repos that exceed the size of your own system. Version control systems like Piper (Google internal) and Eden (Facebook), GitVFS (Microsoft) already do this, but adoption is marginal.
If you're not going to commit to fixing downstream packages for other teams when you change something, it doesn't make a lot of sense to have a monorepo. Instead, let people upgrade at their own pace.
My main issue with Git, other than the terrible UX of the CLI, is just how common it is for one to want to rewrite the commit history - an operation for which there's no version control. You better get it right, or otherwise you get to nuke the whole repository.
My main issue with Git, other than the terrible UX of the CLI, is just how common it is for one to want to rewrite the commit history - an operation for which there's no version control. You better get it right, or otherwise you get to nuke the whole repository.