5 ms·

I love these posts. I bookmark all of them. I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of im

I love these posts. I bookmark all of them. I feel strongly that VCS's could have much better UX and reliability. I'm trying to design one myself instead of implementing it in a weekend. (Though I do understand the constraints Linus was under when he made Git.) I'd love to hear more about what people hate about Git.

hotnfresh 3y ago
> I'd love to hear more about what people hate about Git. It's not implemented as a single portable library. This makes embedding or driving git from other programs—a thing I've wanted or needed to do several times in my career, so I'm pretty sure it's really common—suck a lot more than it needs to.
- gavinhoward 3y ago
  Good to know. I'll make mine a library and tool, like SQLite.
- rascul 3y ago
  Have you looked into libgit2? https://libgit2.org/ https://libgit2.org/
  - hotnfresh 3y ago
    1) It’s not at feature parity, And 2) It’s not the official implementation, so using it is committing to debug and work around divergence between it and actual git, probably after production or otherwise in-use data have been messed up.
miohtama 3y ago
Back in a day, late 00s, early 10s, Git had alternatives. - Bazaar - Mercurial (Hg) Both had superior user experience compared to git, including command line and GUIs. They were not as fast, but no slow either if you came from Subversion world. They were not as flexible, but still very very flexible. What caused Git to win was not rants of Linus Tolvards, but Github. Github gave Git a semi-understandable web user interface. Early days, Github itself had a lot of competition. Bitbucket (now Atlassian) was the same but for Mercurial. However, Github, as a good American startup, won over the world, popularising Git along the way. (Also Stackoverflow helped a lot. There isn’t a day I won’t Google how to do basic things in Git.)
- Qwertious 3y ago
  BitBucket no longer supports Mercurial, only Git. Thankfully, SourceHut does support Mercurial (and, IIRC, it also supports Fossil).
- jamseason 3y ago
  > Both had superior user experience compared to git Highly subjective. Both Mercurial and Bazaar were plagued a long time by muddled branching and collaboration story. In hg there were the anonymous branches, multiple repos, bookmarks, all worked in different ways and their interactions were confusing. Bazaar I didn't use much but remember not understanding at all its branching model then, and didn't bother finding out. Git won because it got many things right from the start, and was better than the competition.
- Izkata 3y ago
  Back then, when I had only subversion experience, I tried both git and mercurial, and found mercurial really confusing. Ended up using git for everything, the way it worked just made sense to me. Unfortunately it's been long enough that I don't remember any details about why I found mercurial confusing.
- sgbeal 3y ago
  > (Also Stackoverflow helped a lot. There isn’t a day I won’t Google how to do basic things in Git.) Back in 2011 or 2012 i once had one of the libgit developers sitting at my workstation for a full hour trying un-hose my local checkout after i'd made the mistake of following git instructions from SO. SO git advice: 0 of 5 stars. Cannot recommend.
- CableNinja 3y ago
  git gained popularity way before github/gitlab. Its popularity stemmed from the features that CVS and SVN were severely lacking. Github just made it easier to share and discover projects, and it happened to use git. It also helps that github was not a target for foss, instead it was started as a business. Before then, git, cvs, svn, were all foss projects and hosted (usually mostly) by the project owners.
codetrotter 3y ago
Will your VCS be compatible with git pull, git push, and the file format on disk used by git?
- gavinhoward 3y ago
  No. I'll be using SQLite and weave files in order to handle massive amounts of data (terabytes or more) while having full transactions.
  - fanf2 3y ago
    How do weave files cope with history diverging across copies, moves, and deletes? How do they handle file/directory conflicts across different branches?
    - gavinhoward 3y ago
      History diverging is only a problem if the same branch is different across different checkouts. Since Git's branches are a bookmark, this is a problem for Git. My tool has full branches, and your master branch is considered a different branch than the default master of the origin remote. And to handle them across branches, each branch will have its own weave file, rooted at a parent. (There will be some optimizations.)
IshKebab 3y ago
Yeah I think the point about monorepos vs submodules is probably the biggest non-usability issue with Git. In a very large project you can have a monorepo, and then everything is slow and you can't easily use and work on a subset of the code. Or you can use submodules and then testing, refactoring and making commits all become a nightmare. Binary files is another crap area of Git. LFS is useless. Lots of people have Stockholm syndrome and think that Git doesn't support large/binary files well because it's immoral rather than just because it's not something Linus ever needed. I'm still a bit sad that most of the attempts at replacing Git focus on the poor conflict resolution story (which is poor but tolerable) rather than these more fundamental issues.
- gavinhoward 3y ago
  > Yeah I think the point about monorepos vs submodules is probably the biggest non-usability issue with Git. As a lone developer, I admit that this is what surprises me the most about the experience of other people. But I'm going to solve it. Partial checkouts, fully-transactional cross-submodule commits, the works. Really, these problems are easy with a good design. It's unfortunate that Linus didn't have time for design. > Binary files is another crap area of Git. LFS is useless. Lots of people have Stockholm syndrome and think that Git doesn't support large/binary files well because it's immoral rather than just because it's not something Linus ever needed. Yeah, I don't get this either. I am implementing a general plugin system for creating format-aware operations. This will include source code and binary files. > I'm still a bit sad that most of the attempts at replacing Git focus on the poor conflict resolution story (which is poor but tolerable) rather than these more fundamental issues. I fully agree. I'm going to the doing UX studies, and that's my first priority. I am going to handle conflict resolution better, though.
domador 3y ago
Many years ago, when I was looking for a worthy DVCS successor to Subversion for my single-developer projects (just in case they became multiple-developer projects), I evaluated Git, Bazaar, and Mercurial. I don't really remember what were the deciding factors, but I ended up going with Mercurial. I'm sure usability was a big part of it, since that's a major value for me, and I really didn't like git in that department. I think I also read some things that made me distrust git's handling of data, but don't remember the specifics. git just seems messy in other ways as well. I still wonder to this day whether the wrong DVCS won the popularity contest and became an unfortunate default option for developers.
UweSchmidt 3y ago
Scrap the thing entirely and replace it with something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. Folders instead of branches. Be 100% language-aware; any merge result has to build obviously. If this rejects actions and limits possibilities that Git provides, so be it.
- gavinhoward 3y ago
  I agree. You laid out my current design in a nutshell, actually. Except for folders. But my branches will be more than a bookmark.
  - UweSchmidt 3y ago
    In your design, can I go to the other "branch/folder" and look around / copy over that binary to my current "branch/folder" in a file explorer without a "checkout"?
    - gavinhoward 3y ago
      Not in a file explorer, sadly. However, I was going to make a browser UI from the start. I could implement a branch and file explorer in that UI, which would allow you to do the same thing. Would that be good enough or not? I'd love to know because I want to build this tool for humans first.
      - UweSchmidt 3y ago
        Probably, yes. Anything that does not require thinking in current Git-logic. I don't mind Git that much in everyday work but if something nicer came along, that would be great. I do think that Git is very well established, and it would probably take a major player, maybe Azure or AWS with a cloud-based IDE to change paradigms.
        gavinhoward 3y ago

hotnfresh 3y ago

> I'd love to hear more about what people hate about Git. It's not implemented as a single portable library. This makes embedding or driving git from other programs—a thing I've wanted or needed to do several times in my career, so I'm pretty sure it's really common—suck a lot more than it needs to.

gavinhoward 3y ago
Good to know. I'll make mine a library and tool, like SQLite.
rascul 3y ago
Have you looked into libgit2? https://libgit2.org/ https://libgit2.org/
- hotnfresh 3y ago
  1) It’s not at feature parity, And 2) It’s not the official implementation, so using it is committing to debug and work around divergence between it and actual git, probably after production or otherwise in-use data have been messed up.

miohtama 3y ago

Back in a day, late 00s, early 10s, Git had alternatives. - Bazaar - Mercurial (Hg) Both had superior user experience compared to git, including command line and GUIs. They were not as fast, but no slow either if you came from Subversion world. They were not as flexible, but still very very flexible. What caused Git to win was not rants of Linus Tolvards, but Github. Github gave Git a semi-understandable web user interface. Early days, Github itself had a lot of competition. Bitbucket (now Atlassian) was the same but for Mercurial. However, Github, as a good American startup, won over the world, popularising Git along the way. (Also Stackoverflow helped a lot. There isn’t a day I won’t Google how to do basic things in Git.)

Qwertious 3y ago
BitBucket no longer supports Mercurial, only Git. Thankfully, SourceHut does support Mercurial (and, IIRC, it also supports Fossil).
jamseason 3y ago
> Both had superior user experience compared to git Highly subjective. Both Mercurial and Bazaar were plagued a long time by muddled branching and collaboration story. In hg there were the anonymous branches, multiple repos, bookmarks, all worked in different ways and their interactions were confusing. Bazaar I didn't use much but remember not understanding at all its branching model then, and didn't bother finding out. Git won because it got many things right from the start, and was better than the competition.
Izkata 3y ago
Back then, when I had only subversion experience, I tried both git and mercurial, and found mercurial really confusing. Ended up using git for everything, the way it worked just made sense to me. Unfortunately it's been long enough that I don't remember any details about why I found mercurial confusing.
sgbeal 3y ago
> (Also Stackoverflow helped a lot. There isn’t a day I won’t Google how to do basic things in Git.) Back in 2011 or 2012 i once had one of the libgit developers sitting at my workstation for a full hour trying un-hose my local checkout after i'd made the mistake of following git instructions from SO. SO git advice: 0 of 5 stars. Cannot recommend.
CableNinja 3y ago
git gained popularity way before github/gitlab. Its popularity stemmed from the features that CVS and SVN were severely lacking. Github just made it easier to share and discover projects, and it happened to use git. It also helps that github was not a target for foss, instead it was started as a business. Before then, git, cvs, svn, were all foss projects and hosted (usually mostly) by the project owners.

codetrotter 3y ago

Will your VCS be compatible with git pull, git push, and the file format on disk used by git?

gavinhoward 3y ago
No. I'll be using SQLite and weave files in order to handle massive amounts of data (terabytes or more) while having full transactions.
- fanf2 3y ago
  How do weave files cope with history diverging across copies, moves, and deletes? How do they handle file/directory conflicts across different branches?
  - gavinhoward 3y ago
    History diverging is only a problem if the same branch is different across different checkouts. Since Git's branches are a bookmark, this is a problem for Git. My tool has full branches, and your master branch is considered a different branch than the default master of the origin remote. And to handle them across branches, each branch will have its own weave file, rooted at a parent. (There will be some optimizations.)

IshKebab 3y ago

Yeah I think the point about monorepos vs submodules is probably the biggest non-usability issue with Git. In a very large project you can have a monorepo, and then everything is slow and you can't easily use and work on a subset of the code. Or you can use submodules and then testing, refactoring and making commits all become a nightmare. Binary files is another crap area of Git. LFS is useless. Lots of people have Stockholm syndrome and think that Git doesn't support large/binary files well because it's immoral rather than just because it's not something Linus ever needed. I'm still a bit sad that most of the attempts at replacing Git focus on the poor conflict resolution story (which is poor but tolerable) rather than these more fundamental issues.

gavinhoward 3y ago
> Yeah I think the point about monorepos vs submodules is probably the biggest non-usability issue with Git. As a lone developer, I admit that this is what surprises me the most about the experience of other people. But I'm going to solve it. Partial checkouts, fully-transactional cross-submodule commits, the works. Really, these problems are easy with a good design. It's unfortunate that Linus didn't have time for design. > Binary files is another crap area of Git. LFS is useless. Lots of people have Stockholm syndrome and think that Git doesn't support large/binary files well because it's immoral rather than just because it's not something Linus ever needed. Yeah, I don't get this either. I am implementing a general plugin system for creating format-aware operations. This will include source code and binary files. > I'm still a bit sad that most of the attempts at replacing Git focus on the poor conflict resolution story (which is poor but tolerable) rather than these more fundamental issues. I fully agree. I'm going to the doing UX studies, and that's my first priority. I am going to handle conflict resolution better, though.

domador 3y ago

Many years ago, when I was looking for a worthy DVCS successor to Subversion for my single-developer projects (just in case they became multiple-developer projects), I evaluated Git, Bazaar, and Mercurial. I don't really remember what were the deciding factors, but I ended up going with Mercurial. I'm sure usability was a big part of it, since that's a major value for me, and I really didn't like git in that department. I think I also read some things that made me distrust git's handling of data, but don't remember the specifics. git just seems messy in other ways as well. I still wonder to this day whether the wrong DVCS won the popularity contest and became an unfortunate default option for developers.

UweSchmidt 3y ago

Scrap the thing entirely and replace it with something that uses intuitive metaphors like "save", "load", "undo", "go back to old version", "update my work with work from colleague", "update the official state with my work" and others. Folders instead of branches. Be 100% language-aware; any merge result has to build obviously. If this rejects actions and limits possibilities that Git provides, so be it.

gavinhoward 3y ago
I agree. You laid out my current design in a nutshell, actually. Except for folders. But my branches will be more than a bookmark.
- UweSchmidt 3y ago
  In your design, can I go to the other "branch/folder" and look around / copy over that binary to my current "branch/folder" in a file explorer without a "checkout"?
  - gavinhoward 3y ago
    Not in a file explorer, sadly. However, I was going to make a browser UI from the start. I could implement a branch and file explorer in that UI, which would allow you to do the same thing. Would that be good enough or not? I'd love to know because I want to build this tool for humans first.
    - UweSchmidt 3y ago
      Probably, yes. Anything that does not require thinking in current Git-logic. I don't mind Git that much in everyday work but if something nicer came along, that would be great. I do think that Git is very well established, and it would probably take a major player, maybe Azure or AWS with a cloud-based IDE to change paradigms.
      - gavinhoward 3y ago