> It's not safe to run git submodule update if you've made and committed changes within a submodule without checking out a branch first. They will be silently overwritten:
"Silently overwritten" are not words you want to be associated with a version control system.
I think submodules are a bit of a failed experiment, yes. Or, perhaps, a work in progress. Their usability is just awful. That said, if you don't use them the rest of git works just fine. ;)
Does Mercurial support submodules or the equivalent? Not in core, from what I can tell, although a casual search of Google reveals the third-party "Forest Extension":
There's some talk on a wiki about putting this extension's functionality into Mercurial proper, but the wiki link is broken. That doesn't bode well. I don't know Mercurial so I have no idea if Forest is actually being used by folks, if it's akin to git submodules or more akin to Braid, if it's got usability traps of its own, etc. The docs page is filled with TODOs.
We use Forests and they are pretty awful. I would recommend against using that extension. It is awkward to work with, makes it hard to rollback your repos to a consistent state, and is painful when you have a change that applies to both repos.
Aha, perhaps I have found the Mercurial equivalent of git submodules! ;)
Although, actually, I'm pretty sure you can get git projects with submodules to roll back to consistent states. But it might take ten separate commands, five attempts, and a visit to the FAQ. Submodules are conceptually tricky and their workflow is a mess.
Sound exactly like forests. You CAN get back to a consistent state. But you have to be very careful look at the commit history and hg update a few times.
I've used forests on a few projects. On the upside, the commands don't cause unpleasant surprises; it's easy to guess what they'll do. But there are still far too many extra steps to do simple things like clone a remote forest and get all the sub-projects up to date. They need an "hg jfdi" command.
svn's externals work quite well, on the other hand. I know, I know, svn is so 2007, but after fiddling around a bit with git, my impression is that spending time writing code is an order (if not more) of magnitude more important thank screwing around with a version control system, and svn mostly 'just works'. I think that eventually things like git and hg will surpass it, but version control isn't where your startup is going to "make or break" it (unless you're github:-).
I've settled into a pretty happy workflow using Git as a local snapshot of an upstream Subversion repository using git-svn. With a bit of discipline, you can keep things nicely in sync, and get the benefits of cheap-as-hell branching and local/offline commits without forcing your entire project team to migrate to a new VCS.
Well, I know nothing of SVN externals. But I tend to believe this guy who says that SVN externals are inferior to Piston, and that Piston is the equivalent of git's Braid:
He strikes me as someone who has come by this lesson through direct, painful personal experience.
I've settled on Braid for the moment, and we'll see how that goes. Submodules offer more features, but at the expense of my ability to explain them to anybody else.
I found them quite painful. Links to external paths don't work, committing with multiple externals when one or more of the external repos are down has some sort of problem (though it's been a while and may have been fixed), doing anything from the external to the parent (like moving files) had some sort of problem as well (again, maybe fixed). It was enough of a problem that the project I was working on ended up with two repositories for the same code...and they would manually merge them periodically. Obviously sub-optimal and a big waste of time, but it was less trouble than the alternative of having every developer understand why the external repo had to be treated completely differently from the rest of the repository in many regards.
Forests are out of date, but IIRC mpm is planning on personally tackling submodule support for release some time this summer (whenever the 1.3 release schedule is, I don't remember offhand).
When Unix-like goes so far as to include windows with MSys, what does it exclude? And, for windows users that don't like to type, there's tortoisegit (http://code.google.com/p/tortoisegit/), which appears to be generally functional.
Mercurial is still better supported under Windows. Anecdotal evidence: compare the Eclipse plug-ins (under Windows) for git and hg. (And before there's flak about Eclipse: it is a widely used tool, under Windows at least).
Git not working well on Windows is something that continues to tarnish its reputation even though that hasn't been the case for quite some time.
Curiously, this was part of the reason Python chose not to use Git even after extensive research. One would have thought they would have stumbled across any number of projects like msysgit that would have shown them otherwise.
I say this as a git user: msysgit works well, but that's not the same thing as working well on Windows. hq feels native on Windows in a way that git doesn't.
Having just installed hit on windows, the feeling I got was that there is msysgit, or running it on cygwin. Msysgit's homepage feels... Precarious, like it's part abandoned.
It does work, once you answer a question of which of three ways it should awkwardly integrate into your PATH, but within a cygwinesque bash shell.
So yeah, functional but nowhere near as smooth and seamless as python on windows is, or as one might pick up from your comment.
Second, where are all these points whenever someone asks about git? All you ever seem to get in return are fanboys trumpeting git as the second coming, even here on HN.
where are all these points whenever someone asks about git?
If you go looking for rough edges in an open-source Unix power tool that's under development... you're going to find them.
Based on my research (but, please note, not much actual experience) git submodules are ugly, confusing, and perhaps even dangerous in the hands of anyone but an expert. I avoid them. That said, it appears that lots of Rails developers use them every day and can't live without them. Should this feature have been kept out of the official git release, just because it's still being worked out? Not an easy question to answer. Every project maintainer has a different philosophy about such things, and there are a lot of judgement calls to be made.
My issue is not that they exist. I've got no problem with warts in software. I don't think there's a project anywhere that doesn't have some sort of issue.
What I take issue with however is that these warts get conveniently forgotten in the buzz. Even worse, I'd be willing to bet that most of those rails dev's have no idea what is solid and what's a work in progress; they're being done a disservice, really.
I suppose my concern is that there's a fine line between enthusiasm and hype, and it's difficult to know when you've crossed the line.
What I take issue with however is that these warts get conveniently forgotten in the buzz
The problem, to paraphrase Tolstoy, is that happy users are all alike, but every unhappy user is unhappy in her own way.
It's easy to write a review that talks about the core features that a tool gets right. Everyone cares about those features, and everyone uses them, and they're well documented. It is much harder to write a review containing a categorical list of warts. Warts are incidental problems that only bother a subset of users. (If they bothered absolutely everybody, they wouldn't be called warts; they'd have a different name: bugs or misfeatures.)
Worse, one person's wart is another person's feature. Legions of people have complained, over the decades, that rm has a horrible and dangerous UI which lets you accidentally erase your entire machine by typing a stray space at the wrong time. But, somehow, rm persists, because there are plenty of power users who like it.
There are warts and there are warts. When there are warts in some kind of cool experimental toy, that's one thing, but there are other systems that should be as solid and reliable as possible. Things like backups, and, yeah, version control.
I saw that quote re: PyCon and eagerly googled for 'Brett Cannon', pycon, git and only found the same announcement time and again without any explanation as to why git was disqualified.
Is anyone here involved closely in the python community who could maybe shed some light on what made git inadequate for their needs?
I believe the initial consensus was that a Python-based version control system was greatly preferred over anything else, and that for Git to be considered someone would have to show that it's much more compelling than the other systems. Git was allowed into the PEP later on, however.
Besides being able to say they're eating their own dog food, I think having the ability to easily extend their version control system was a factor in the choice. The Python developers would just be writing Python, after all, and Mercurial has a very simple extension system.
I believe Guido has had direct communication with some of the core developers of Mercurial as well, which was probably another factor. I'm not sure what Brett's DVCS usage survey had to say about Mercurial or Git, but that could also play a role in his decision.
Here's the original thread that led up to the PEP: http://thread.gmane.org/gmane.comp.python.devel/98191. From what I understand, there wasn't supposed to be a lot of discussion until the PEP was written, but people couldn't help but voice their opinions on the matter. I'm guessing this is why Guido put his foot down: to prevent an endless religious debate. Hopefully the PEP will be revised with a more detailed explanation of his rationale.
> At PyCon, Brett already announced that Git was no longer being considered -- while it has obviously many fans, it also provokes strong antipathies.
And I'm starting to see why. It has... issues. One I ran into recently:
http://book.git-scm.com/5_submodules.html
> It's not safe to run git submodule update if you've made and committed changes within a submodule without checking out a branch first. They will be silently overwritten:
"Silently overwritten" are not words you want to be associated with a version control system.