Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Version Control Beyond Git

soundbarrier.io

Post reply on HN
Print view View original

11–18 of 18 posts

Re: Version Control Beyond Git

#11

Post by oneofthose »

brylie wrote: post #3

> 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/

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

Re: Version Control Beyond Git

#12

Post by oneofthose »

jmclnx wrote: post #6

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 :)

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.

Re: Version Control Beyond Git

#13

Post by oneofthose »

thunderbong wrote: post #7
brylie wrote: post #4

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

If your team is small, fossil is perfect. https://fossil-scm.org/ (it's mentioned in the article)

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.

Re: Version Control Beyond Git

#14

Post by oneofthose »

nomilk wrote: post #5
brylie wrote: post #4

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

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

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...

Re: Version Control Beyond Git

#15

Post by NikkiA »

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.

Re: Version Control Beyond Git

#16

Post by NikkiA »

jmclnx wrote: post #6

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 :)

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.

Re: Version Control Beyond Git

#17

Post by mos_basik »

brylie wrote: post #4

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

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.

Re: Version Control Beyond Git

#18

Post by pmeunier »

oneofthose wrote: post #10
kevincox wrote: post #9

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 m…

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.

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.

Post reply on HN