3 ms·

So Git is what Linus thinks is good. What I think is good, and this was Git's inspiration, is at http://bitkeeper.org http://bitkeeper.org It's very different

So Git is what Linus thinks is good. What I think is good, and this was Git's inspiration, is at http://bitkeeper.org http://bitkeeper.org It's very different from Git. Git versions the tree, BK versions the tree and versions files. The difference is profound. In BK, you debug by looking at the file history and then zooming out to the commit history. Git can't do that. Or it fakes it and gets it wrong. Same with merges, renames, creates, deletes, Git gets all that wrong. I know it won and there is no hope that things can get better but if you want to see what better looks like, check out BK.

corndoge 9y ago
you said git is wrong but don't explain why bk is right
- luckydude 9y ago
  It's all about what is recorded, git records less information. Git has no versioned file object, it has one graph for the whole repository, there are no per file graphs. Which means there are no create/delete/rename events, git guesses at that information. BK has a graph per file in addition to the repository graph. The pathname is an attribute of the file, just like the contents. The per file graph means the GCA you use when you merge is the correct one for this file, not the one for the repository. The two might be miles apart, so we make merging easier. One more: it's easy to write (and we did) a bk fast-export and have it work deterministically so that incremental exports work correctly even when done in parallel in trees not at the same place. We wrote a bk fast-import but we can't get it to work correctly incrementally, git doesn't record enough information. At this point, I really wish Linus had just copied our tech, the world would have improved. Git is a step, a big step, backwards and we are stuck with it.
  - deleted 9y ago
    [deleted]
kazinator 9y ago
git repos with non-linear history quickly turn to shit. The only way to use git right is never to allow a commit to have two parents. Never merge anything: always cherry pick or rebase.
mappu 9y ago
Hg user here. One interesting hg/git difference is that Hg allows file history across renames by explicitly tracking the rename operation, whereas git just does a fuzzy content match.

corndoge 9y ago

you said git is wrong but don't explain why bk is right

luckydude 9y ago
It's all about what is recorded, git records less information. Git has no versioned file object, it has one graph for the whole repository, there are no per file graphs. Which means there are no create/delete/rename events, git guesses at that information. BK has a graph per file in addition to the repository graph. The pathname is an attribute of the file, just like the contents. The per file graph means the GCA you use when you merge is the correct one for this file, not the one for the repository. The two might be miles apart, so we make merging easier. One more: it's easy to write (and we did) a bk fast-export and have it work deterministically so that incremental exports work correctly even when done in parallel in trees not at the same place. We wrote a bk fast-import but we can't get it to work correctly incrementally, git doesn't record enough information. At this point, I really wish Linus had just copied our tech, the world would have improved. Git is a step, a big step, backwards and we are stuck with it.
- deleted 9y ago
  [deleted]

kazinator 9y ago

git repos with non-linear history quickly turn to shit. The only way to use git right is never to allow a commit to have two parents. Never merge anything: always cherry pick or rebase.

mappu 9y ago

Hg user here. One interesting hg/git difference is that Hg allows file history across renames by explicitly tracking the rename operation, whereas git just does a fuzzy content match.