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

1–10 of 18 posts

Re: Version Control Beyond Git

#3

Post by brylie »

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

Re: Version Control Beyond Git

#6

Post by jmclnx »

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

Re: Version Control Beyond Git

#8

Post by bananapub »

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

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

Re: Version Control Beyond Git

#9

Post by kevincox »

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)

Re: Version Control Beyond Git

#10

Post by oneofthose »

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.
Post reply on HN