| ▲ | forrestthewoods 5 days ago |
| Git is fundamentally broken and bad. Almost all projects are defacto centralized. Your project is not Linux. A good version control system would support petabyte scale history and terabyte scale clones via sparse virtual filesystem. Git’s design is just bad for almost all projects that aren’t Linux. (I know this will get downvoted. But most modern programmers have never used anything but Git and so they don’t realize their tool is actually quite bad! It’s a shame.) |
|
| ▲ | codethief 5 days ago | parent | next [-] |
| > A good version control system would support petabyte scale history and terabyte scale clones via sparse virtual filesystem. I like this idea in principle but I always wonder what that would look in practice, outside a FAANG company: How do you ensure the virtual file system works equally well on all platforms, without root access, possibly even inside containers? How do you ensure it's fast? What do you do in case of network errors? |
| |
|
| ▲ | ants_everywhere 5 days ago | parent | prev | next [-] |
| Yeah we're at the CVS stage where everyone uses it because everyone uses it. But most people don't need most of its features and many people need features it doesn't have. If you look up git worktrees, you'll find a lot of blog articles referring to worktrees as a "secret weapon" or similar. So git's secret weapon is a mode that lets you work around the ugliness of branches. This suggests that many people would be better suited by an SCM that isn't branch-based. It's nice having the full history offline. But the scaling problems force people to adopt a workflow where they have a large number of small git repos instead of keeping the history of related things together. I think there are better designs out there for the typical open source project. |
| |
| ▲ | matheusmoreira 5 days ago | parent | next [-] | | I don't understand what you mean by "the ugliness of branches". In my experience, branches are totally awesome. Worktrees make branches even more awesome because they let me check out multiple branches at once to separate directories. The only way it could get better is if it somehow gains the ability to check out the same branch to multiple different directories at once. | | |
| ▲ | 1718627440 4 days ago | parent [-] | | > ability to check out the same branch to multiple different directories at once. So you want shared object storage, but separate branch metadata. That's git clone with hardlinks, which is what Git does locally by default. | | |
| ▲ | matheusmoreira 4 days ago | parent [-] | | Git worktrees won't allow me to check out a branch twice though. I wonder if there's some technical limitation that prevents it. | | |
| ▲ | 1718627440 4 days ago | parent [-] | | That is, because the metadata is shared between worktrees. So you when you modify a branch in one worktree, it isn't modified per worktree, but in the whole repo. So what you need to do is to duplicate the branch metadata. That's what git clone does. You essentially have these cases: shared worktree, shared branch/index data, shared object storage -> single repo, single worktree
separate worktree, shared branch/index data, shared object storage -> repo, with worktrees
separate worktree, separate branch/index data, shared object storage -> git clone
separate worktree, separate branch/index data, separate object storage -> git clone --no-hardlinks
You can checkout a commit twice though. What I don't get is what checking out a branch twice gets you. As soon as you add a single commit, these branches will be different, so why not just create another branch? Branches in git are cheap. | | |
| ▲ | matheusmoreira 3 days ago | parent [-] | | Makes sense to me, thank you. It's just something I tried to do once. I didn't think very hard about it so it felt like an arbitrary limitation. What I tried to do was have two copies of the same branch checked out to a different directory: one pristine, another with uncommitted changes. The idea was to run make on both directories, profile the results and then decide whether to commit or discard the changes. Now I see the solution is to just make another branch. | | |
| ▲ | 1718627440 3 days ago | parent [-] | | Yeah in this case I wouldn't probably even bother with branches and only checkout the commit. Another way to solve this problem are of course VPATH-builds. |
|
|
|
|
| |
| ▲ | DonHopkins 5 days ago | parent | prev [-] | | Git now has artificial feet to aim the foot guns at so they hit the right target. |
|
|
| ▲ | matheusmoreira 5 days ago | parent | prev [-] |
| Completely disagree. Git is fundamentally functional and good. All projects are local and decentralized, and any "centralization" is in fact just git hosting services, of which there are many options which are not even mutually exclusive. |
| |
| ▲ | compiler-guy 5 days ago | parent | next [-] | | Got works fine and is solid and well enough known to be a reasonable choice for most people. But I encourage everyone to try out a few alternatives (and adopt their workflows at least for a while). I have no idea if you have or not. But fine has never used the alternatives, one doesn’t really know just how nice things can be. Or, even if you still find fit to be your preferred can, having an alternative experience can open you to other possibilities and ways of working. Just like everyone should try a couple of different programming languages or editors or anything else for size. You may not end up choosing it, but seeing the possibilities and different ways of thinking is a very good thing. | |
| ▲ | ItsHarper 5 days ago | parent | prev | next [-] | | Yeah, the decentralized design is incredibly useful in the day-to-day, for ~any project size. | | |
| ▲ | forrestthewoods 5 days ago | parent [-] | | Incorrect. All the features you think are associated with the D in DVCS are perfectly accessible to a more centralized tool. | | |
| ▲ | 1718627440 4 days ago | parent | next [-] | | Either you have all data local or you need to send the data around as soon as you traverse or modify history. No not having everything local would be a massive downside for some operations. | | |
| ▲ | forrestthewoods 4 days ago | parent [-] | | Nonsense. Be specific. Google, Meta, and every large game studio on the planet use large centralized monorepos. It's not only fine, it's great! If you use Git it's not possible to "have everything" because Git is not capable of storing everything that needs to be version controlled. Most devs their version control is actually a combination of Git, docker images, and lord knows how many other data sources. It's a miserable nightmare. Good luck and God speed to anyone who tries to build something from just a few years ago, never mind a 10+ year old project! | | |
| ▲ | 1718627440 4 days ago | parent [-] | | I'm not talking about what needs to be in Git and what not, I mean for git functionality that analyzes the history (git blame), the data needs to be traversible, i.e. available locally, fetching it over the wire will introduce massive latency. You claimed it doesn't need to be. > All the features you think are associated with the D in DVCS are perfectly accessible to a more centralized tool. | | |
| ▲ | forrestthewoods 3 days ago | parent [-] | | Git Blame sucks and is far far far far far far worse than Perforce Timelapse View. You moved the goal posts a little bit. You are correct that if you want to work in a cave with no internet then you do need every bit of data to perform at least some operation. That’s not what the D in DVCS means though. | | |
| ▲ | 1718627440 3 days ago | parent [-] | | That's exactly what the D means: All the repo data is on every machine, the repo is complete in itself and no repo is any different than the other. For me connecting to the Internet is very much a choice. Doesn't mean I wouldn't have access if I didn't want to, but why would I need it most of the time? |
|
|
|
| |
| ▲ | yencabulator 3 days ago | parent | prev [-] | | One of the features I think is associated with the D is the ability to work offline with full access to everything in my repository. |
|
| |
| ▲ | the_arun 5 days ago | parent | prev [-] | | Are you missing the central hosting services provide a good backup plan for your locally hosted git? | | |
| ▲ | matheusmoreira 5 days ago | parent [-] | | I agree! They are excellent git backup services. I use several of them: github, codeberg, gitlab, sourcehut. I can easily set up remotes to push to all of them at once. I also have copies of my important repositories on all my personal computers, including my phone. This is only possible because git is decentralized. Claiming that git is centralized is complete falsehood. |
|
|
