That's the entirety of git. Extremely fast. Bummer UI. It's status quo and no changing. Despite using git for 10+ years, I frequently have to look up commands and then I end up scratching my head as to why the CLI UI is like that.
You can have a 'pull, merge, push'-only system, but at that point we're re-inventing subversion. So making it more advanced would mean we also need to have the knowledge and skills to do other activities correctly and that means the tooling can't make as many choices for you because there simply isn't a default way that works all the time.
Most efforts at git-alternatives run in to the same problems and either they'll be just as advanced and have the samen benefits and downsides or they end up less advanced but now it's not equally useful and you can't really make it work right.
GitHub has come a long way. But I would guess the main reason it managed to become dominant is not because it had a better product. (At the time, it didn't.) It's because Git benefited from the celebrity of its author, Linus Torvalds.
(Nowadays mercurial can do rebase/amend just fine.. But it is too late)
I do like to squash and rebase before moving changes upstream. But, to me, that isn't really history quite yet. Or at least, it's not history that's worth recording. All those micro-commits from the work in progress are, in some ways, more akin to my editor's undo history. Which is also something I don't save.
It's also clear, in hindsight, that Mercurial's original position on this subject failed to anticipate AWS credentials accidentally being committed to source control.
But I have also seen (and done) some amount of history rewriting in long-lived branches that I don't think would have been necessary if Git had had some of Mercurial's ergonomics. Workflows for merging two different repositories while retaining the commit history from each, for example.
Although once stuff is pushed to the public repo you're probably going to want to change those keys regardless. And if it's on the local one, there's plenty of options for removing the commit.
It was also much slower than git. But I knew someone working on Google Code at the time who liked it better because it was "clean" and in Python.
Some other things it was slower, that's changed over time ofc.
Also, in terms of clean history, mercurial has best of both worlds with phases and hidden by default commits to keep track of such cleanup.
Yeah, it has more features now but at the time it didn’t. There was something called patch queue you could use for early stage work but that was all.
It's been long enough I don't remember the details about why I didn't like mercurial, but fame power had nothing to do with it, nor did website integration - I was only using it locally. How it worked just didn't fit with how I thought about version control.
Git has and always had a singularity bad UI amongst dvcs.
So? Maybe Subversion is all most developers need?
Git doesn't even technically have branches, just pointers to commits which can easily get mixed up, go headless and fail out in ways that just never happened in SVN.
And rebasing a branch with several commits can be a nightmare since you have to re-merge almost (but not exactly) the same code over and over again at whatever state it was in at some time in the past when some previous commit happened - unless you abort out and squash first. In SVN, you just merged the whole branch once and when both were in their final current state.
Of course, git's a lot more powerful, but with that comes complexity. SVN branching and merging was a snap comparatively.
* https://subversion.apache.org/docs/release-notes/1.10.html#c...
* https://subversion.apache.org/docs/release-notes/1.11.html#c...
I mean, if that's a reason to say git doesn't technically have branches, then neither does svn. It has subdirectories that you can make copies of at any level, and copy commits between them at any level, such that you can make an amazing repo-within-a-repo mess not possible in git.
Sure, CVS was limited but it was reliable and straightforward.
It was so reliable that people complained about SVN using a DB (Berkeley DB) as backend, as manual fixing of CVS files was a "normal" part of operation and people didn't believe that might not be needed ...
Like I’m gonna bother to set up a Subversion remote for every little repo that I create for myself.
This means you usually only have one svn repo, and you set it up the way you like. As an example, you may set things up so you can checkout:
server:/proj/small/hello - to get a single project
server:/proj/small- to get all small projects
server:/proj - to get all projects
If you already have one of those checked out, adding new project is as simple as "mkdir bar", "svn add bar", "svn commit". So juch easier than making new github repo. And multi-level hierarchical project nesting is still something impossible in git.
Were you paying attention to what I just wrote!? `git init`. What do I need a remote on the Internet for?
But yes, if all your work is on one machine, and you have backups of it, there is not much point in svn.
Being distributed, it solved the main gripes with SVN; it also added a better merging algorithm (https://foswiki.org/pub/Development/SVK/svk-visual-guide.pdf), solving another big gripe.
I was actually satisfied of it, and surprised that it never got attention, in particular, because there were no requirements in order to use it with existing SVN repositories. I'm actually baffled, because SVN is still active, so SVK would still be useful nowadays.
I used subversion for a long time and was resistant to moving ardour.org to use git instead. 24hours after we switched (we never use 3rd party git hosting as our canonical repo), I was already convinced it was not the right choice, but an excellent choice.
Sure, we use one canonical repository. All our “pull requests” are really merge requests, mostly to the main branch. So that’s pretty centralized, right? So why use a distributed VCS? Well, why use a local editor or IDE for code that is ultimately going to end up in the cloud somewhere? Sure, you might want to out of preference, but why should you be forced to? The fact is that wherever the code will end up is besides the point when it comes to how to develop it.
The truly important thing about distributed VCS is that it forces almost all of the operations on the repository to be usable locally. And why should it not be? What’s “git log”, “git blame”, or “git merge” got to do with whether there is one canonical repo or a hierarchy of upstreams?
I think that this idea that non-distributed VCS is somehow the default—as in the obvious, simple thing to implement—is just backwards. Of course the default assumption for any VCS operation—unless it has a name like “send-email”—should be that it operates on your own local copy.
Sure, we use a centralized repo structure. And the only call-central-command operation I use is “git push”. All the other fiddling and querying—and all the things that make version-control-as-history useful—is local.
I think there is a reason why this XKCD was made: https://xkcd.com/1597/
It will work fine over a Windows share, Samba, NFS, and so on. It doesn’t need svn or http protocol to operate.
SVN doesn't work peer-to-peer or over email. And that's fine. It's just not ready to go with only local tools.
Of course, you can use GitHub with Subversion just fine, but that wasn't the point. The point was that Subversion alone is never enough if you want to collaborate.
That’s a bummer. It would help us point the discussion in the right direction.
> SVN doesn't work peer-to-peer or over email.
Why not? What is so different about people having their own subversion repositories over file protocol vs people having their git repositories?
Why would you not be able to send a subversion patch in an email?
As someone who uses git for 10 years, I understand it may not be as ergonomic as with git. But why not?
> The point was that Subversion alone is never enough if you want to collaborate.
Why not? Is git enough?
Older systems like CVS are also still in use, but it appears that none of the old systems really lasted more broadly and aren't useful for the needs of today.
It's what enables three-way merges, and makes rebasing much more manageable.
The ability to traverse and jump to some other point in history is really missing here too.
Local commits imply traversing history, but even that is terrible with Git. You can't just do obvious things like "git previous" or "git next" or "git checkout <commit hash>".
Also, git checkout <commit hash> works?
What happens if you amend a commit after checking it out?
Hm. We must use git completely differently then. I can't really imagine what what I'd do without them.
> there's nothing they convey that commit messages don't express better.
Presumably you'd still want to maintain a list of HEADs, so you just want to alway refer to them by hash instead of a branch name? That's fine I guess -- not sure what it buys you.
> What happens if you amend a commit after checking it out?
Then it becomes a new commit? Not sure what you're getting at.
Not entirely true: checkout was split into switch and restore, which is something I guess.