3 ms·

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 d

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.

DonHopkins 1y ago
Git now has artificial feet to aim the foot guns at so they hit the right target.
matheusmoreira 1y ago
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 1y ago
  > 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 1y ago
    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 1y ago
      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 1y ago
        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 1y ago
        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 1y ago

Git now has artificial feet to aim the foot guns at so they hit the right target.

matheusmoreira 1y ago

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 1y ago
> 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 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
        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.