I’m so excited. I’ve just made a proof of concept of the article-syndication idea I previous wrote about. The proof of concept is entirely demonstrated on GitHub.
- Submodules in Git were whole branches/repositories
- Files in submodules cannot diverge from the original.
So Submodules were out, until the Git team upgrade them to a) allow maintained divergence, and b) sub-directories to be tracked rather than the whole repo.
How I’ve pushed past that
Easy. Just use the Subversion support on Github. Read on …
A hypothetical case
We going to syndicate a single file from one repo to another. Actually that’ll be a single directory because of a subversion limitation. We’re not going to track anything else from the original repo, and for fun, we’re going to map it into another directory. We’re going to have a modification to the original, and a separate modification to the syndicated one.
The timeline for that case
Step by step
Both repos exist on GitHub, as this isn’t just a hypothetical case.
The first is a pure Git thing that has a single resource that’s relevant. That resource a file called “test” in a sub directory called ‘subdir’. Here, take a look at its history
As you can see, ‘test’ has two commits. One that is the copy/paste from wikipedia for some of their ‘Lorum Ipsum’ page.The second is the addition of some other text, specifically -
The second repo was created empty. I made it after the first commit for repo #1, and before the second commit that added “its fleece was white as snow”. Repo #2 has a directory called ‘foo’. Inside that I did:
svn checkout https://github.com/paul-hammant/little-experiment/trunk/subdir
Yes, that’s created ‘subdir’ its pesky .svn folder and the ‘test’ file that we wanted. Subversion maintains the .svn folder and some of the things within it are text, and some binary. It even has a second copy of ‘test’. Don’t sweat that. We want it, and we’re going to check it in to Git/GitHub. Git’s Compression will reduce the cost of the duplicate. Here is the history for ‘subdir’. Click that and you’ll see:
The the right of the three number in red boxes, are buttons to navigate to the three commits. The first commit ‘354a3fd8d4’is the original ‘test’ file being checked in (twice because of that .svn folder). The second commit added “Mary had a little lamb” like so:
The third commit was where, on the command line, I did ..
cd foo/subdir svn up cd ../.. git commit -m "upstream publications changes pulled into syndicated version (that had maintained divergence)"
It merged the upstream text change without complaint. Of course given I checked in the .svn folder, it’s changed a bunch of stuff in there too. I’m not particularly worried about that, as it is a small cost for the ‘maintained divergence’ that I’m wishing for.
After that Merge, Subversion thinks the file is modified. Too bad, it’s not going to be committed back to any Svn repo:
cd foo/subdir svn st M test
Ordinarily you would never use Git and Subversion like this together, but I am very deliberately ignoring the Git-Svn best practice and toolchain. See the “Previous Blockers” above.
We should also consider a ‘tooling cost’ to this design. Specifically ‘git pull’ is not going to do ‘svn up’ for you. You’re going to need a new mechanism to check for (or consume) upstream changes. Similarly, the upstream repository is not going to find it easy to take back cherry-picked changes which is desirable for spelling and other corrections.
The directory ‘subdir’ has to be syndicated because of a limitation of subversion’s checkout. All we really wanted was ‘test’, but we have to have the director too. That said, it can easily be renamed under Git, and still be connected to the correct directory upstream.
Yeah, and I kinda wish I’d done some examples using Jekyll and markdown articles to simulate how newspapers or content publishers would do this.