I rarely ever care about progression of time and version, and the author doesn’t make a good case for why I should in the case of FreeBSD. It seems like a very fussy distinction.
At first I thought I was going to miss svn “r1234” numbers and considered putting a server-side update hook on a central server there which automatically tagged pushes to ‘master’ with.
I never ended up feeling the need, but given it’s just a few lines of bash perhaps it’d be worth trying and see if people use the sequential numbers or if they’re just a distraction.
This makes me sad. I’d love FreeBSD to change a few things to encourage contribution and everytime these ideas come up they seem to be shot down with arguments like this.
Maybe the current system works and encourages high quality contribution due to the higher barrier to entry but in the end I think encouraging folks to contribute and making it easier to so correctly is in the best interests of the project.
I feel the Rust community does this well with the use of bots to automate some aspects of the process. There are some details of that in this article.
Wonder what he thinks of fossil and mercurial.
The fossil author deliberately disallowed rewriting history; he makes
a good case for it. At one time, Mercurial history was immutable too,
but I believe this has changed.
I guess my point is that there are DVCS out there that satisfy his criteria;
they’re just not git.
History can never be truly immutable so long as the data is stored on mutable media like a hard disk. Refusing to package tools that do it just makes people who need the feature find/build 3rd party tools
About Mercurial, I believe it has always allowed rewriting history, but not by default — you have to change your configuration files to opt-in to all the “dangerous/advanced” features.
in many cases Git is an adequate substitute for a VCS, you just
have to augment it with an out-of-band definition of which tree is
the ‘definitive’, and settle who gets to define what ‘a version’
means
Agreed, and in fact I think this is what makes git better than a version control system. It exposed the underlying good parts of VCS that we actually want.
If the distinction being drawn is ‘admin’ vs ‘user’ tooling, I guess - like workflow - git punts that to the surrounding culture and environment (as it does “which version is the ‘master’” - which is the same feature/bug of any DVCS).
I admit I like being able to say “v234” but really, what that means is “v234 of the (single) upstream repo which can change any time the upstream repo manager runs svnadmin”.
There’s nothing to stop github putting a sequential “v1, v2, v3, …” on commits to master or otherwise blessing some workflow.
I think the differences aren’t so much about features + capability and tooling as culture.
Yes it is, but no - that’s not what I meant. I mean that I expect every VCS to be able to rewrite history since the data files are under control of the admin. git can do it, svn can do it. You can edit RCS files by hand if you want to (unsure if there is tooling to do it).
i.e. linus can rewrite his git history. It will be out of sync with other people, but that is then a social issue, not a technical one (I admit this is a fine point).
The only time you can’t rewrite history is in the “public immutable” world of blockchain - since the data files aren’t under your control. I don’t know if someone has built a vcs like that and my comment was really just a side swipe at blockchain hype.
I rarely ever care about progression of time and version, and the author doesn’t make a good case for why I should in the case of FreeBSD. It seems like a very fussy distinction.
At first I thought I was going to miss svn “r1234” numbers and considered putting a server-side update hook on a central server there which automatically tagged pushes to ‘master’ with.
I never ended up feeling the need, but given it’s just a few lines of bash perhaps it’d be worth trying and see if people use the sequential numbers or if they’re just a distraction.
This makes me sad. I’d love FreeBSD to change a few things to encourage contribution and everytime these ideas come up they seem to be shot down with arguments like this.
Maybe the current system works and encourages high quality contribution due to the higher barrier to entry but in the end I think encouraging folks to contribute and making it easier to so correctly is in the best interests of the project.
I feel the Rust community does this well with the use of bots to automate some aspects of the process. There are some details of that in this article.
Another data point I saw the other day was since moving to GitLab some gnome projects have seen a noticeable uptick in contribution: https://twitter.com/hergertme/status/1009538945439297536
Wonder what he thinks of fossil and mercurial. The fossil author deliberately disallowed rewriting history; he makes a good case for it. At one time, Mercurial history was immutable too, but I believe this has changed.
I guess my point is that there are DVCS out there that satisfy his criteria; they’re just not git.
History can never be truly immutable so long as the data is stored on mutable media like a hard disk. Refusing to package tools that do it just makes people who need the feature find/build 3rd party tools
Do you see people doing that? I mostly see people just accepting the limitations and dealing with it.
The site seems down now :(
About Mercurial, I believe it has always allowed rewriting history, but not by default — you have to change your configuration files to opt-in to all the “dangerous/advanced” features.
This sounds like the old tired line “RAID is not backup”. Which is true, nobody disagrees, and so it is pointless to keep repeating.
FWIW, I continually have discussions with people that believe having a distributed database means they don’t need backups.
It’s less about someone actively disagreeing it’s about people naively thinking it’s the same concept
Agreed, and in fact I think this is what makes git better than a version control system. It exposed the underlying good parts of VCS that we actually want.
Don’t all VCSs have tools to modify history? I think svnadmin does: http://oliverguenther.de/2016/01/rewriting-subversion-history/ (assuming there aren’t any blockchain-based VCSs. I daren’t look)
If the distinction being drawn is ‘admin’ vs ‘user’ tooling, I guess - like workflow - git punts that to the surrounding culture and environment (as it does “which version is the ‘master’” - which is the same feature/bug of any DVCS).
I admit I like being able to say “v234” but really, what that means is “v234 of the (single) upstream repo which can change any time the upstream repo manager runs svnadmin”.
There’s nothing to stop github putting a sequential “v1, v2, v3, …” on commits to master or otherwise blessing some workflow.
I think the differences aren’t so much about features + capability and tooling as culture.
git is a merkle-tree-based system, which is what I assume you meant by “blockchain-based” in this context
Yes it is, but no - that’s not what I meant. I mean that I expect every VCS to be able to rewrite history since the data files are under control of the admin. git can do it, svn can do it. You can edit RCS files by hand if you want to (unsure if there is tooling to do it).
i.e. linus can rewrite his git history. It will be out of sync with other people, but that is then a social issue, not a technical one (I admit this is a fine point).
The only time you can’t rewrite history is in the “public immutable” world of blockchain - since the data files aren’t under your control. I don’t know if someone has built a vcs like that and my comment was really just a side swipe at blockchain hype.
you can if you get 51%
https://github.com/clehner/git-ssb not exactly blockchain, but immutable history just the same.