I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket). I switched to git mainly because my colleagues were all using it. I found it difficult to use, at first, because of my expectation of a central repo. Many years in, however, I see extreme value in having all your history locally. Specifically, never having to worry about a server crashing or your "host" going out of business.
back
4 comments
Same. I didn't get what was better about a distributed system for small projects, until it fully clicked with me that my copy was just as "official" as any other sitting around, and that any "server" was a copy that we collectively decided was going to be the one of record. I can't imagine any plausible scenario in which I'd go back to having a central SVN-style server.
Having an official central server is precisely what you want in most development environments. Being able to go back to any prior version of the code is tremendously useful and something git can't do.
For most of us, even with DVCS there is one copy of the repos that is more important than all the rest - the one attached to the CI or deployment tools. It’s only decentralized as long as this copy has only short periods of unavailability. Hours are bad, days are much worse.
Linus seems to have a very different development model than almost all of the rest of us. And if Linus is asynchronous, then so is the codebase he maintains.
If you or I have eight different PRs going it’s because we have eight different promises being made to customers. Rejecting them has real consequences that we feel. For Linux many of those are externalities.
> I actually LIKED having a central repository, which many of us still seem to prefer (i.e. GitHub, GitLab, Bitbucket).
You're confusing a hosting service with being forced to use a centralized repository.
Take GitHub, for example. If git was centralized them you would not have forks, multiple remotes or multihosting, or could even work independently of the remote server.
With Git, you can even set up a repo in a network file system somewhere, or even a USB thumbrive.
Git makes it easier to do a fork but you could certainly fork a subversion repo. I’m fairly certain you could sort of a merge process across multiple upstreams.
Git does far more than making it easy to fork: it makes it trivial and inexpensive.
Meanwhile SVN supports forking in the sense that it supports copying directories.
The "fork" concept is not native to neither Subversion nor git.
You are probably thinking of branches and tags, and those are used similarly in both systems. They are a bit more convenient in git since they are created in constant as opposed to linear time.
Copies in Subversion are only metadata. Since partial clones are native to the system, it is simple to present both branches and tags as file paths. It was likely considered an easy user interface. Everything is a file and all that. In comparison, git users must learn the git object naming scheme, otherwise things can end up very confusing should you have a directory and a branch with the same name.
> You are probably thinking of branches and tags,
No, I was referring to forking projects, in the sense that Git allows for creating brand new and independent repositories that clone the version history up to a point in time and enable to add the origin Git repository as a remote repository.
SVN also does not support branching or tagging, as it actually supports only copying directories around a file system.
> They are a bit more convenient in git since they are created in constant as opposed to linear time.
I would argue that branches are nicer in git because it makes merging so much easier.
Having history available locally also means you can perform interesting operations on history -- like "git blame" -- without making the server do all the heavy lifting.
Yeah, other than locking I would argue that a DVCS is better at even the things a non-distributed VCS is good at.
The problem is, is that git will happily destroy history. git blame is not useful because it doesn't tell you who authored the line of code.
Right, especially after a "squash", which seems to be the standard way to merge branches in the companies I've been working with recently. (Which is, ironically, also the way Subversion merges branches. With the exception that "svn blame -g" will go into the commits which were squashed if you want. An option which doesn't exist after a "squash" on Git.)
> The problem is, is that git will happily destroy history.
No, people will happily destroy history. Git is just a tool.
Fossil's opinion on this is that history is an immutable record of project history. It may be messy and unfortunate at times, but it is what happened, and it shouldn't be altered in place any more than you'd do that with an accounts ledger.
In extremis, Fossil offers the "shun" command to remove improperly-committed artifacts, but even then it's subject to a lot of restrictions. (https://fossil-scm.org/fossil/doc/trunk/www/shunning.wiki)
> Fossil's opinion
Tools don't have opinions, people do. Fossil is just inflexible.
You don't want to alter history? Don't do it then. Git supports not altering history just fine.
I can't control what other users of the repo are doing, so it's not that simple.
If you are their superior, other users disregarding your orders is s social problem, not a technical one. If you aren't, it's a good thing they are able not to do what you want.
Tools being more flexible is strictly a good thing. If they are misused, the person that misused them is responsible. It is that simple.