|
1 | 1 | <?xml version="1.0" encoding="utf-8"?> |
2 | | -<feed xmlns="http://www.w3.org/2005/Atom"><title>Generic Surname</title><link href="http://jrsmith3.github.io/" rel="alternate"></link><link href="http://jrsmith3.github.io/feeds/all-en.atom.xml" rel="self"></link><id>http://jrsmith3.github.io/</id><updated>2014-06-26T00:00:00-04:00</updated><entry><title>Scratchwork branches</title><link href="http://jrsmith3.github.io/scratchwork-branches.html" rel="alternate"></link><updated>2014-06-26T00:00:00-04:00</updated><author><name>Joshua Ryan Smith</name></author><id>tag:jrsmith3.github.io,2014-06-26:scratchwork-branches.html</id><summary type="html"><p>I have a question that I'd like to pose to more advanced software developers if any are out there.</p> |
| 2 | +<feed xmlns="http://www.w3.org/2005/Atom"><title>Generic Surname</title><link href="http://jrsmith3.github.io/" rel="alternate"></link><link href="http://jrsmith3.github.io/feeds/all-en.atom.xml" rel="self"></link><id>http://jrsmith3.github.io/</id><updated>2014-10-12T00:00:00-04:00</updated><entry><title>Merging a subdirectory from another repo via git-subtree</title><link href="http://jrsmith3.github.io/merging-a-subdirectory-from-another-repo-via-git-subtree.html" rel="alternate"></link><updated>2014-10-12T00:00:00-04:00</updated><author><name>Joshua Ryan Smith</name></author><id>tag:jrsmith3.github.io,2014-10-12:merging-a-subdirectory-from-another-repo-via-git-subtree.html</id><summary type="html"><p>Greg Wilson <a href="https://twitter.com/jiffyclub/status/519920529038262272">wanted to know</a> how to move a directory from one git repo to another while preserving history. Ash Wilson posted a <a href="https://gist.github.com/smashwilson/015e6a3abfbf7af73d31">gist</a> demonstrating a merge and delete strategy. A similar result can be achieved using <code>git-subtree</code>. The advantage of the <code>git-subtree</code> approach is that <code>git-subtree</code> creates a new branch containing only the commits pertaining to files located in a specified subdirectory. Like Ash's approach, <code>git-subtree</code> will result in the final state of the target repo is such that changes to the target repo won't get pushed back upstream to the source.</p> |
| 3 | +<p>If you want to carry <em>all</em> of the commit history from another repo into the target repo, Ash's approach is probably the way to go. If you want only the commits pertaining to files within a subdirectory of the source repo, <code>git-subtree</code> is the way to go.</p> |
| 4 | +<p>The workflow with <code>git-subtree</code> is pretty simple: you specify a subdirectory in a source repo which you want to break out, then you merge those commits into a subdirectory in a target repo.</p> |
| 5 | +<p>I am modifying my example slightly from Ash's because it looks like the <code>/openstack-swift/</code> directory has been removed from jclouds/jclouds-labs-openstack as of 2014-10-12. I will use <code>openstack-glance</code> instead. Thus, we're moving the <code>/openstack-glance/</code> directory from jclouds/jclouds-labs-openstack to <code>/apis/openstack-glance/</code> in jclouds/jclouds. The two approaches begin in the same way.</p> |
| 6 | +<div class="highlight"><pre><span class="cp"># Clone the target repo</span> |
| 7 | +<span class="n">git</span> <span class="n">clone</span> <span class="n">git</span><span class="err">@</span><span class="n">github</span><span class="p">.</span><span class="n">com</span><span class="o">:</span><span class="n">jclouds</span><span class="o">/</span><span class="n">jclouds</span><span class="p">.</span><span class="n">git</span> |
| 8 | +<span class="n">cd</span> <span class="n">jclouds</span> |
| 9 | + |
| 10 | +<span class="cp"># Add the source repository as a remote, and perform the initial fetch.</span> |
| 11 | +<span class="n">git</span> <span class="n">remote</span> <span class="n">add</span> <span class="o">-</span><span class="n">f</span> <span class="n">sourcerepo</span> <span class="n">git</span><span class="err">@</span><span class="n">github</span><span class="p">.</span><span class="n">com</span><span class="o">:</span><span class="n">jclouds</span><span class="o">/</span><span class="n">jclouds</span><span class="o">-</span><span class="n">labs</span><span class="o">-</span><span class="n">openstack</span><span class="p">.</span><span class="n">git</span> |
| 12 | + |
| 13 | +<span class="cp"># Create a branch based on the source repositories&#39; branch that contains the state you want to copy.</span> |
| 14 | +<span class="n">git</span> <span class="n">checkout</span> <span class="o">-</span><span class="n">b</span> <span class="n">staging</span><span class="o">-</span><span class="n">branch</span> <span class="n">sourcerepo</span><span class="o">/</span><span class="n">master</span> |
| 15 | + |
| 16 | +<span class="cp"># Here&#39;s where the two approaches diverge.</span> |
| 17 | +<span class="cp"># Create a synthetic branch using the commits in `/openstack-glance/` from `sourcerepo`</span> |
| 18 | +<span class="n">git</span> <span class="n">subtree</span> <span class="n">split</span> <span class="o">-</span><span class="n">P</span> <span class="n">openstack</span><span class="o">-</span><span class="n">glance</span> <span class="o">-</span><span class="n">b</span> <span class="n">openstack</span><span class="o">-</span><span class="n">glance</span> |
| 19 | + |
| 20 | +<span class="cp"># Checkout `master` and add the new `openstack-glance` branch into `/apis/openstack-glance/`. At this point, the desired result will have been achieved.</span> |
| 21 | +<span class="n">git</span> <span class="n">checkout</span> <span class="n">master</span> |
| 22 | +<span class="n">git</span> <span class="n">subtree</span> <span class="n">add</span> <span class="o">-</span><span class="n">P</span> <span class="n">apis</span><span class="o">/</span><span class="n">openstack</span><span class="o">-</span><span class="n">glance</span> <span class="n">openstack</span><span class="o">-</span><span class="n">glance</span> |
| 23 | + |
| 24 | +<span class="cp"># Clean up by removing the commits from the `openstack-glance` branch and the `sourcerepo` remote.</span> |
| 25 | +<span class="n">git</span> <span class="n">branch</span> <span class="o">-</span><span class="n">D</span> <span class="n">openstack</span><span class="o">-</span><span class="n">glance</span> <span class="n">staging</span><span class="o">-</span><span class="n">branch</span> |
| 26 | +<span class="n">git</span> <span class="n">remote</span> <span class="n">rm</span> <span class="n">sourcerepo</span> |
| 27 | +</pre></div> |
| 28 | + |
| 29 | + |
| 30 | +<p>And that's it. No additional (potentially superfluous) commits were brought into the <code>jclouds</code> repo from the <code>jclouds-labs-openstack</code> repo.</p></summary></entry><entry><title>Scratchwork branches</title><link href="http://jrsmith3.github.io/scratchwork-branches.html" rel="alternate"></link><updated>2014-06-26T00:00:00-04:00</updated><author><name>Joshua Ryan Smith</name></author><id>tag:jrsmith3.github.io,2014-06-26:scratchwork-branches.html</id><summary type="html"><p>I have a question that I'd like to pose to more advanced software developers if any are out there.</p> |
3 | 31 | <p>Yesterday I wrote some code and tests to implement some medium-complex functionality (branch <code>surf_enh</code> in the picture). The result was ok, but I ended up with a situation where I had painted myself into a corner. So today I started over pretty much from scratch; I reverted back to the point in the repo where I had started yesterday, and applied the lessons I had learned (branch <code>slab</code>) while avoiding the cul-de-sac I ended up in yesterday. A lot of the code in <code>slab</code> is copied from <code>surf_enh</code> with some minor modifications.</p> |
4 | 32 | <p><img alt="Two days' work." src="images/two_days.png" /></p> |
5 | 33 | <p>My question is: what do I do with branch <code>surf_enh</code>? I'm thinking about this branch in terms of an early draft of a manuscript; some days you write copy with the understanding that you will pretty much completely rewrite it from scratch on a subsequent revision. When I write manuscripts or papers, I like to keep earlier revisions for posterity. Similarly, I would like to keep the commits and commit messages in <code>surf_enh</code>. However, it seems like keeping a whole named branch in the repo would be crufty.</p> |
|
0 commit comments