Why are git submodules incompatible with svn externals?

Question

There are lots of webpages out there suggesting hackish ways to make svn externals look like git submodules. I have read some accounts of what the difference is, but this doesn't seem very fundamental:

Git submodules link to a particular commit in another project's repository, while svn:externals always fetch the latest revision.

Why does this difference make them so fundamentally incompatible? Isn't there a reasonable default we can assume, such as that most svn:externals point to tags that never move?

Columbite

Note that, as detailed in https://mcmap.net/q/13005/-git-submodule-tracking-latest and mentioned in my updated answer below, a submodule now can track a branch latest. – Fontes

Answer 1

The fundamental difference is the composition rule.

In a true component-based approach, you define a configuration, that is:
The list of labels (of SHA1 commits for Git) you need for your project to "work" (i.e. "develop", "compile", "deploy", ...).

Each commit referenced in a configuration helps you to get the exact versions of all trees. There is no exception. Each file of that tree is at the exact version specified by the configuration you have defined.

---

Note for git1.8.2

"git submodule" started learning a new mode to integrate with the tip of the remote branch (as opposed to integrating with the commit recorded in the superproject's gitlink).

So soon (March 2013), a submodule could reference an upstream HEAD, and not just a fixed SHA1.

---

(Before 1.8.2) There can be only one label/SHA1 per module. From one common parent repo, you cannot define a module within a module.
(But a module, which is just a reference to an external Git repo, can have its own submodules definition: the parent repo will only refer the first-level submodule, which in turn will reference whatever submodules it had committed within itself)

---

No so in SVN external: you can define directory externals as well as file external, with or without an explicit revision in it.
You can compose various external properties. For instance:

$ svn propget svn:externals calc
third-party/sounds             http://svn.example.com/repos/sounds
third-party/skins -r148        http://svn.example.com/skinproj
third-party/skins/toolkit -r21 http://svn.example.com/skin-maker

The result is not a configuration (one reference for 'calc'), but a composition of selection rules which define the exact "patchwork" you need in the directory 'calc'

---

In short, you cannot "compute" one SHA1 for a 'calc' submodule which would be the exact equivalent of a bunch of svn:external properties on a 'calc' SVN directory.

Fontes

Note to self: ClearCase is another example of VCS allowing composition in its version selection mechanism... except it has banished such a mode with its more recent methodology UCM: see stackoverflow.com/questions/763099/… – Fontes

Nicely written. But... When you're checking out the SVN parent, whether the externals have moved or not, you expect it to compile and work. So wouldn't it me sufficient, at least as a default, to hash that particular revision, when you git svn clone the parent? – Columbite

@Andres: how would you git svn dcommit then? How would you push back any changes you could have made within the "submodule" part of your Git repo (see "true nature of submodules" https://mcmap.net/q/12700/-git-submodule-update/…), which actually correspond to several SVN repo, some of them with an explicit revision not supposed to move? – Fontes

This is still deeply unsatisfying. I get that they're different,but I don't get why there can't be some automatic workaround. – Columbite

Answer 2

If you use SmartGit for working with SVN repository with svn:externalls, you won't notice any real difference.

Actually, the only real difference (at least the only technical difference) is that SVN allows external to point to HEAD revision (not fixed value), Git submodule doesn't. All the other differences are, to my opinion, insignificant, so you're right asking this question.

Barbarous