Version Control Beyond Git

Version Control Beyond Git(soundbarrier.io)

5 points by oneofthose 1 year ago | 16 comments

NikkiA 1 year ago |

Most of these are owned by some megacorp, which IMO renders them untrustable, the same may have been true for git at a time (I can't remember if Linus still "worked for" redhat at the time of git's creation), but it's sufficiently insulated from that now - even if MS is viewed as holding github's reins too closely. But I'm not trustly a VCS from facebook, or even google.

The real issue is though, that each time someone writes a new VCS they seem to want to make it centralised again, often with silly ideas like auto-uploading changes. I do dislike the git stash and the "mess" of untracked files in git status, but I'm not sure what the true answer is.

kevincox 1 year ago |

The feature I think I would most like to see is support for patches as a more first-class object. For example reverts and cherry picks have no real metadata. This leads to conflicts when merging branches that have cherry picks (although they often auto-resolve if they are exactly the same diff) and makes asking "Does $branch contain $patch" basically impossible to answer.

https://pijul.org/ greatly improves this by making patches a first class object (and commits are basically sets of patches). I think it has some great ideas to improve the really gnarly parts of Git low-level behaviour. (Not just surface-level UI issues)

oneofthose 1 year ago | |

Is there a design doc one could study? At a high level I understand how the fact that patches are commutative is elegant, but it seems to me there are performance impacts when, to get to a repository state, we have to apply many patches. Would love to read how pijul thinks about that.

pmeunier 1 year ago | | |

This is indeed one of the issues of Pijul, but patch application is extremely fast, which makes it easy in the vast majority of cases (we don't apply patches to files directly, but to an on-purpose on-disk datastructure).

We also have a tag features, allowing you to pinpoint versions and go back instantly, and we have plans to make that feature even lighter on disk space.

brylie 1 year ago |

> Mercurial was started almost at the same time as Git by Olivia Mackall, a kernel hacker at the time, motivated, just like Linus, by the BitKeeper and SourcePuller drama of spring 2005.

Perhaps ironically, the now open-source BitKeeper may meet many of the author’s criteria for a post-Git version control system, at least at first glance from the BitKeeper homepage.

https://www.bitkeeper.org/

oneofthose 1 year ago | |

That is indeed somewhat ironic. It does not seem particularly active, with the last and the last release more than 1 year ago.

jmclnx 1 year ago |

I think git is OK, but one item I miss is what CVS/RCS has, "$Id$". It is very difficult to see the version of a binary if its source is tracked in git.

Yes, someone said there is a way to get a git tag in the source, but the tag is not as easy to view as "$Id$" thus it is not obvious if it is the latest version.

But, curious he did not mention CVS and RCS :)

oneofthose 1 year ago | |

I would consider CVS and RCS worth studying for historical reasons, since they have no releases for over a decade (according to Wikipedia). I was considering incorporating the history of version control, but there is already a great one here: https://blog.plasticscm.com/2010/11/version-control-timeline... -- it has a great comment section as well. Maybe it would be interesting to create an updated version of the article.

As for "$Id$", in bazel you would use https://bazel.build/docs/user-manual#workspace-status which works very well and can differentiate between stable and volatile.

NikkiA 1 year ago | |

Hilariously, that exact feature was posted here a couple of weeks ago, and roundly decried as being the worst thing about that era of CVS, and how horrible it was that it made reproducible builds impossible.

bananapub 1 year ago | |

> It is very difficult to see the version of a binary if its source is tracked in git.

come on, this should be done by your build system. it's pretty silly to not put this tiny amount of work in.

brylie 1 year ago |

What would be your top choice for a post-Git VCS and why? I’m interested to try alternatives.

mos_basik 1 year ago | |

I feel that to be qualified to answer your question I need to have used a non-git VCS on a non-trivial project. Which I haven't.

That said, jujutsu is the one that's most sparked my interest and seems most akin to the subset of git features that I use in my daily workflow. (In the way that everyone apparently uses a different subset of C++, I imagine everyone uses a different subset of git.)

This blogpost was what made me try it: https://v5.chriskrycho.com/essays/jj-init/ which I found from this recent HN thread https://news.ycombinator.com/item?id=39232456. Other HN threads about it: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...

That said, I haven't kept experimenting with it cause I had to stay productive (same reason I still haven't switched to Colemak). But I still have the tab open. And I did eventually switch to i3. So, maybe one day.

thunderbong 1 year ago | |

If your team is small, fossil is perfect.

https://fossil-scm.org/

(it's mentioned in the article)

oneofthose 1 year ago | | |

I think fossil is not exactly post-git but runs in parallel with git. But definitely a good fit for small teams. For true post-git if you feel adventurous I would try jj or pijul.

nomilk 1 year ago | |

I'm a happy git user, although I've heard great things about lazygit: https://github.com/jesseduffield/lazygit?tab=readme-ov-file

oneofthose 1 year ago | | |

Yes I think for git users there are a number of great gui and tui and cli tools to simplify workflows. Here is a good list: https://github.com/dictcp/awesome-git?tab=readme-ov-file#cli...