Revision Control Systems suck
My recent series of posts in which I had some difficulty with GIT (1, 2, 3) have garnered a lot of interest, and generated some discussion. Many of the replies saw the funny side, which is nice as I was hoping to be at least amusing (rants are, after all, a form of entertainment) and more than I expected sympathised. Many tried to help by giving me a sequence of commands that might work, ironically often the exact same commands I used in my original post.
And many told me I was an idiot, and that they had no problem; and that I should learn how to use GIT instead of just stabbing at guesses.
Those made me realise what the fundamental difference between myself and them are.
I don’t want to use a revision control system.
It follows that if I don’t want to use one, I certainly don’t want to waste time learning one! I don’t want to use a text editor either, again it’s just something that gets in the way of what I really want to do.
I want to write code, and I want to fix bugs and test the fixes.
Actually, I don’t really want to fix bugs; but it’s one of those things you have to do as a responsible software author and maintainer. Now, I sadly can’t just write code by thinking about it. Even though I use zsh, holding down the TAB key just doesn’t write my code for me, so I have to use a text editor.
And I hate them, especially emacs, which is the text editor I use. I keep hoping that one day Anjuta or something like MonoDevelop will be usable for writing and debugging C – but alas, that day has not yet come. (Incidentally, if a developer would like some constructive criticism from my side, I would be perfectly happy to do give it – just grab me on IRC).
Now I don’t have to use a Revision Control System, unlike a text editor which is somewhat essential, but there are a lot of advantages to using one. In particular, I think I have two primary use cases:
- Keeping a history of my changes
- Sharing my work with others, and allowing others to share their work with me.
Since I don’t want to use a Revision Control System, it should be as simple and painless to use as possible. I have probably a dozen common actions that I do; so each of these actions should be just one command, with no options or flags to make them do the right thing. For bonus points, these commands should be obvious and ideally have aliases for the similar commands in other systems for easier learning.
Here’s the first set:
- get a copy of some source code, to which I can make my own changes if I wish
- save my current set of changes to the history
- put a copy of my source code, with changes, somewhere others can get at it
- update my source code with changes made to where I got it from
We could probably call these get, commit, push and pull. Note that I’m not allowing for any kind of add, move or remove command. Such things are a pain in the neck; my most common preference is just for any changes I’ve made to be committed. This is probably one big reason why GIT and I don’t get on so well; it’s written for somebody else’s use case where the most common use case is committing nothing.
Since I pretend to like other people working on my software, I’ll need a couple of commands for doing that:
- review the changes somebody else’s source code makes to mine
- add the changes they’ve made to my source code.
I’ve yet to see a revision control system that makes the first one easy, which is sad, because it’s just about the most common operation I do on other people’s branches/repositories/clones; I’d call that review, and then we can call the second one merge.
And then for the last set:
- look at the history of changes
- examine the difference between two versions
- extract a single change, in a format compatible with mailing
We can call these log, diff and show (though ideally diff and show would be just the same command with a revision range or single revision).
I’ve probably forgotten something important, but in general, those are the operations I try and do with a revision control system. Thus I can create a Revision Control System Hate Index. The more commands, options or flags it takes to do any of these operations, the higher the Hate Index and the more I’ll loathe it.
GIT scores badly, very few of these operations are a simple command. Many require pre-configuration, many require options and flags to do the right thing. And a couple of them are actually multiple commands.
In fact, GIT’s hate index gets increased further, because after a while you realise that most of the top-level commands very rarely do the right thing. Instead, you start to break down the commands to their fundamentals. If you’ve ever found yourself using git fetch you know what I mean.
This means that I have to stop thinking about writing code, and start thinking about using the revision control system and what the best way to accomplish the operation that I want is. This is a fail that only results in hate.
And just for the peanut gallery, I’d like to point out that Bzr has a non-zero Hate Index as well. In fact, there are misfeatures and bugs in Bzr that make my blood boil just as much as GIT, sometimes even more since Bzr actually claims to always try to do what I mean.
You know what would make me happiest? If I had a text editor that took care of revision control for me. Sometimes I wish there was a Linux version of the good old Borland IDE or at least VisualStudio.
Hey Scott,
the IDE which can do that, is named “Eclipse”.
Eclipse + BZR + BZR-Pugin + PyDEV is my favorite set of tools I use everyday during my worktime and obviously also for Ubuntu development ,-)
I know, I hate Java, but Eclipse is one of good player in the java world.
Regards,
\sh
Agreed on the complexity and the work that git requires you to do.
Then again, I’m not a “real” coder – I don’t want to waste my time googling on how to do every task or being able to fluently converse with hashes.
Take a look at my recent blog posting, Reflections on a complaint from a frustrated git user. I agree with you that one of the most important operations by a maintainer is, as you put it, “review the changes somebody else’s source code makes to mine”.
You’re right that no SCM system has made an easy way to do this, probably because the best way to do this is via e-mail, on a public mailing list. That way other people can participate in the discussion about how the patch can be improved, so hopefully other people will eventually learn your preferences about how code submissions should be done in order for you to submit them. Git is OK on this front; if you want to send a series of patches, you have to use two commands, git format-patches and git send-email, and the CLI UI is probably too complicated. Ideally the git gui should have an easy way of highlighting a series of commits, and then all the user would have to do is click on the “send e-mail” button, with the default patch submission address stored in a .git/config, perhaps with a top-level dot file where that information could be stored on a per-project basis.
It’s actually because of this that I think trying to make “scm push” trivially easy to use is somewhat of a moot point. It’s a good thing to do, for people who are getting started with an scm and who want to trivially be able to share their project with all of their friends. (And in fact, the documentation associated with github and gitorious are pretty good at making this easy).
For the most part, though, if you are submitting changes to some other project, and you are not yet a “trusted lieutenant”, e-mail is actually probably the best way to push patches to the maintainer for review — for most projects, and for most workflows. Your mileage may vary, of course.
If you’re not part of the Gnome/KDE “war”, you could always keep an eye on kdevelop4, which isn’t yet completed but looking as fully fledged as you can get for an IDE…
PS I admit I prefer KDE (though not a fanboy, I like Gnome and XFCE too!)
Emacs handles revision control for you. All revision control commands are only a keystroke away in a system that is consistent across all VCS’es.
I forgot to mention; if you’re just pushing a single patch to a project, you don’t have to use “git format-patch” and “git send-email”; those are best reserved for when you are sending a series of patches, which is a slightly more advanced thing to do. If you are submitting a single simple patch, the best thing to do is simply: “git show | mail list@mailman.host.org“
I would probably second the Eclipse comment from shermann. I have moved to it for most of my Python work. My current work does not involve much coding in C, but the Linux Tools Project of Eclipse (http://www.eclipse.org/linuxtools/, http://overholt.ca/wp/?p=117) definitely looks promising. Maybe you should check it out ? Eclipse also does have a somewhat sane support for Git, which might be useful.
Thanks for the “I want to just code” part though, someone had to say that at some point
You could try Geany (http://www.geany.org/) too.
I don’t understand. These are all very intuitive with bzr and launchpad?
* review the changes somebody else’s source code makes to mine
cd my-branch
bzr missing lp:~username/other-persons-branch
bzr diff lp:~username/other-persons-branch
* add the changes they’ve made to my source code.
bzr merge lp:~username/other-persons-branch
* look at the history of changes
bzr log | less
* examine the difference between two versions
one of these two (identical output)
bzr diff -r1..2 filename.py (shows difference between revision 1 and 2 of file)
bzr diff -c 2 filename.py (shows the changes to file in changeset 2)
* extract a single change, in a format compatible with mailing
bzr send -r last:1 (will launch your platform mailer and send appropriate merge directive for your last commit)
see bzr help revisionspec for all the different -r you can do to get just the changes you want
correction to one of those:
bzr diff lp:~username/other-persons-branch
should have read
bzr diff –new lp:~username/other-persons-branch
I sympathize with your struggle with VCSs. Now, the way I understand it, git is a tool for people who have serious requirements on *organizing* code, and development history, while keeping authorship information intact. It is not something to allow you to quickly share code/modifications.
I believe it is more complex than it should be for some simple tasks, but then again, it used to be even worse just months ago
. What I take from reading your post is you don’t want/need what git is for, so just move along and grab what you like most, and fits your needs. That may as well be quilt, or some Emacs mode.
Now, if a complex project chooses git because of how powerful it is for handling their most important use case… though luck… I also have to use svn/cvs/bzr/hg from time to time. =)
Maybe you should just stop working with computers.
If you’re not hung up on speed, but want to have a very simple yet powerful RCS, I would suggest you look at Darcs. It’s *the* most simplest RCS i have ever seen and used, is extremely easy to explain and understand (easier than Subversion, and much easier than Git). The major problem it has is that it doesn’t scale well with huge codebases and many users committing to the same files, which is why i moved to the much less user-friendly (but much more performant and community-supported) Git.
Hey, I actually do like the “git fetch” command, sorry about that
You’re spot on with that introduction! IMO Git is too centered on the technical side – it’s a marvelous application of graphs and nodes – but as user I do not care about graphs and nodes and the wonderful technical side (at least not when I just want to share some piece of code).
And I suppose that’s a fundamental problem in software development (and it is echoed in many “Usability books”): the focus should be “how can I make an application that helps the user”, not “how do I use graph theory/some awesome network library/GPU-side computation/whatever neat technology to create some other neat software”. It’s a change in attitude, and if it really occurs before starting a project, the resulting product is vastly different and usually much more usable.
I was hoping to be at least amusing
I think the word you are looking for is “tedious”.
Well said! Your views on RCS and editors perfectly fit mine. Now I understand why I hate them so much…
On the other hand, I think Git is the most out-of-the-way VCS I have used. I can just work on files and forget Git completely. If I want to I can commit randomly without thinking good commit messages or anything. THEN I can leave my Emacs and (re)write the recent history in my private branch with “git add –patch” and “git rebase –interactive” so that it is actually useful for other people. And publish it.
Scott,
I think you want to have a revision control system, but you do not want to use it
Perhaps I share your opinion, revision control system are difficult to put in place and to use. Whereas there should be transparent! We should just edit the code, the editor should do the job in the background for us.
That is when we look at a bug (or enhancement) from a website, we should just be able to click “Correct this” and have an editor poping up (hopefully that could be Mozilla Bespin), we do the coding and save. In the background all the revision control management is performed.
Just dreaming
You may want to add some “commit on save” action to your $EDITOR.
While that’s not your point really, at least you can enjoy “git rebase” then before committing..
Please post a follow up. This just keeps getting better.
… have you ever thought about contributing to one of these systems instead of complaining about them? i mean, it would prolly help more… its what i do when i don’t like how something in the free software world works.
What you want indeed is a graphical tool that abstracts you from which commands you should pursue. And MonoDevelop, as you say, is a good candidate because it has Subversion support for this. And now you would say: but suversion is not DVCS!
Well, almost:
http://knocte.blogspot.com/2008/07/subversion-150-highlights-and-some-md.html
Soon it will be
Of course, what you are looking for is EMACS + DVC.
/Mike
@sumfag: lol, tedious just like your last name!
Can’t comment much on git, since I’ve never used it, but I’ve been pulling my hair out with bazaar in similar scenarios. I think half the problem is that the concepts aren’t clearly explained, and not enough examples are given. With subversion, you’ve got the Svn Book which explains things very well, IMO. I guess it also helps that the system is simpler as well, but still, I was able to get up and running with SVN after a few minutes of reading. Sure I was still doing everything wrong from a best-practice standpoint, but I was using it and had very few issues with it. I’ve spent several days trying to figure out bazaar, and I’m still trying to figure it all out.
I appreciate a lot of what you have to say here, but I still love git. Part of that may be that I don’t have your exact use case and I use the GUI tools a lot. Git is actually one of the first RCS where I like those tools and they seem to do what I want.
I like your metric for evaluating it negatively though. Until some sort of magic appears from the sky, I suspect any tool will have a horrible time at somebody’s use case and we’re always going to prioritize those differently.
Based on your requirements, I would suspect that just about any reasonably competent emacs hacker (which does not include me) should be able to provide you with a lisp file that takes a ‘[meta]git+command” sequence looks up the svn meta information from a file related to the rcs system you are using, and does the work for you.
Personally I’m not inclined to be interested in even copy and pasting a command out of an e-mail, or blog response to do a task. Compiling applications has gotten to the point of: download tgz file, untar with ‘tar xzf app.tgz’ ‘cd app’ ‘make’ ’sudo make’; with some variations for bz files, and “./.configure”.
I would suspect that the ’simple’ version control installation should ask you what editor you are using, and set up macros for that. Offer to print a cheat sheet of commands for your editor. and the firs time you invoke a push or get command from within that editor while editing a source file, should ask you for the appropriate information related to that file (credentials, repository, project name, etc.) If you’ve never worked on the project before, but you have a large source file, it should do a collision check on the project name across well known repositories and advise you of any concerns. As part of the initial ‘get’ o fa project, there should be a locally created file in the source path with the appropriate meta information for an existing project that you are contributing to. and you may only be prompted for credential information based on the policies of the project.
Perhaps that’s what emacs+dvc does already, I don’t know. I would not be surprised if eclips+bzr has a built in capability for that. It’s been a very long time since I did any serious development work with any IDE, and I would say that none of what I have done has involved a remote version control platform. But that’s me.
Actually my problem with revision control in general is that they presume that what you are doing is all going to be done through the rcs. My experience in working is that that doesn’t work out quite as well as you would like. In many cases by the time I’m ready to use the RCS, I’ve done most of the revision I’m going to, and the process of ‘checking out, checking in, committing, approving’ and so on has almost no utility for me.But then I’m not developing for large projects, and I’m far from sure that my experience is applicable to development.
What the above poster said. srsly, you’re using emacs and you wish it had something like vc-mode?
“As of 22.1.1 the following version control backends are supported: RCS, CVS, SVN, SCCS, Bzr, Git, Hg, Arch and MCVS. All commands work the same for all backends.”
http://www.credmp.org/2007/12/08/emacs-hidden-gems-version-control/
* look at the history of changes
gitk –all
* examine the difference between two versions
gitk –all
* extract a single change, in a format compatible with mailing
gitk –all
hard. yeah, right. anyway.
* review the changes somebody else’s source code makes to mine
emacs in diff mode? kdiff3?
* add the changes they’ve made to my source code.
git apply/git am
as you can clearly see, git doesn’t meet your requirements.
you don’t want to use a computer, it seems. using a computer implies learning about it. don’t want to learn, change your career path.
Dear snarky holier-than-thou Git users,
Responding in a method such as baczek or Hub did above doesn’t really help your cause. Please go read the Linux Advocacy mini-HOWTO, then extrapolate and apply the concepts within.
Love and hugs,
Jeff
P.S., Scott: I actually do enjoy reading these posts of yours on the topic, and appreciate that you’re willing to stick your neck out to flaming asshat trolls in order to voice your opinions. I also enjoy learning from the commentators who do sincerely want to help and have good information to share; thanks to both, and keep it up!
Git is far from my favorite DRCS — I’m a Bazaar fan because I’ve found it to be the most straight-forward and predictable, with Mercurial running a close second — but there are projects that use it with which I want to or have to work, so any information about how to improve its weaknesses and capitalize its strengths is of great value to me.
If you hate scm systems, you look like you don’t particularly enjoy IDEs either, you don’t enjoy editors, you don’t like fixing things… it even sounds like you don’t really enjoy typing either. What the heck, now I’m confused, what is it that you like? I always thought coders loved a challenge, but you seem to want to have things popup all done without you having to think or do anything. If you hate scms and don’t really want to have anything to do with them, why the bashing posts about them? The problem is obviously yours and not theirs. Weird
@Theodore Tso: Since v1.6.1 git-send-email can invoke git-format-patch in background.
(You would still have to configure it to know how to send email… well, if ‘mail’ works, then git-send-email should also work without configuration).
As a Windows User, I use Tortoise(insert vcs here) to interact with version control systems in my day-to-day. So, you won’t get any command-line kung fu tips from me- I’m just not that cool.
But, I’m certain that it’s a setting of the VCS and *not* the tortoise app, which allows you to choose an external diffing application- That being said, for the “review and accept changes” step that you were saying no VCS handles cleanly, wouldn’t you just specify an external diffing program such as Meld(linux) or WinMerge(windows), which will visually compare the differences and allow you to copy differing regions between files? I confess to having no experience with Git directly, but I have this setting in Hg, and it works quite well.
Random thoughts:
Use ZFS and set it up to take snapshots of the directories where you keep source code very frequently. Or like this: hack together an elisp command that saves the file and takes a snapshot after that, bind to C-x C-s, etc. (Possible downside: OS dependencies, though ZFS-on-FUSE exists.)
Write a simple FUSE file system that’s backed by the RCS that you “need” to use (but don’t “want” to). Save = commit, or something.
They’ll be a PITA to create but you’ll be writing code doing it (without RCS if you so choose) and after it’s done you’ll have revision control “for free”.
“review the changes somebody else’s source code makes to mine”
‘hg incoming’ is good at this; it tells you what changes you’d get by pulling from another repository, optionally showing the patches.
Aegis is a bit heavy weight but it has EVERYTHING, including things like review.
[...] There’s some interesting commentary on revision control systems as a whole on Revision Control Systems suck. [...]
[...] As an example of what seems to be a colossal user interface failure – including poor writing – consider these articles from Scott Remnant which are absolutely a gem (albeit from way back in February 2009). He wrote an article titled Git Sucks – which was then followed by a second and then a third – followed by yet another titled Revision Control Systems Suck. [...]
How about a RCS (CVS, SVN, Git, Bzr, Mircurial) that is integrated into GNOME? *gasp*, oh wait, why should it be so incredibly easy to program using a GUI and have GNOME track your changes, only making you hit a simple button like ‘push’ or ‘upload’…
If life were only that easy.
It’s almost like programmers like doing things the hard way… at least on Linux.
Also I don’t like use a revision control systems.I don’t want to past too much time to learning one! I don’t want to use a text editor either, again it’s just something that gets in the way of what I really want to do.