Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I've used git to stitch together my own github hosted project and an external UI library that I wanted to use. The library is hosted in a subversion repository on sourceforge.</p> <p>I used git-submodule and git-svn and it worked reasonably well. The downsides were:</p> <ol> <li><p>In order to keep up to date with the library repository, I had to perform a new commit to update the submodule git hash "pointer". This is because git submodules, unlike svn:externals, are pinned to a particular commit id. This may not be an actual downside if you actually want to pin a stable version, I was working with code that was WIP.</p></li> <li><p>The initial pull of a git repo with submodules requires an additional step with "git submodule init". This is not an issue for you, but for others using your code they will have to remember or be told to perform this step before compiling/running/testing your code.</p></li> <li><p>If you use the command line it is easy to screw up your repository with git-add. This is because you type <code>git add subm&lt;tab&gt;</code> to complete to <code>git add submodule</code>, but it auto-completes to <code>git add submodule/</code> - note the trailing slash. If you execute the command with the trailing slash, then it blitzes the submodule and adds all its contained files instead. This is mitigated by using git-gui, <code>git add .</code> or just training yourself to delete the slash (it happened to me enough times that I trained myself to remove it)</p></li> <li><p>Submodules commits can mess up git rebase -i. I forget the exact details, but it is especially bad if you have a "dirty" submodule and you run a rebase-interactive. Normally with a dirty tree you can't rebase, but submodules are not checked. Having several submodule commits in a rebase group also causes problems. The last submodule hash gets committed to the first pick on your list, and this is pretty tricky to fix later. This can be worked around with a more careful workflow (i.e. carefully deciding when to do your submodule commits...) but can be a PITA.</p></li> </ol> <p>The steps to set this up were something along the lines of:</p> <ol> <li>Run <code>git svn clone https://project.svn.sourceforge.net/svnroot/project/project/trunk</code></li> <li>Push that as a "real" git project to e.g. github</li> <li>Now in your own git repository, run <code>git submodule init</code></li> <li><code>git submodule add git://github.com/project subproject</code></li> <li>Push that out too, to your own repo this time.</li> </ol> <p>That is it, more or less. You will have a new directory "subproject", which in your case would be the geomapping library.</p> <p>Each time you need to update the geomapping code, you would run something like:</p> <pre><code>cd subproject git svn rebase git svn push # this updates the git mirror of the subproject cd .. git add subproject # careful with the trailing slash! git commit -m "update subproject" git push # this pushes the commit that updates the subproject </code></pre> <p>I've not seen to many tutorials on a git submodule work flow, so I hope this helps you decide.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload