title: A faster way to `git rebase --preserve-merges`
body: <p>I use git by creating a series of feature branches, and merging them to master when they're done with <code>git merge --no-ff</code>. This creates empty merge commits useful to identify start and end points of previous feature branches.</p>
  
  <p>In order to handle multiple concurrent branches, or even nested branches, I use rebase. I never merge back, I always rebase my branches upon the latest commits, test and finally merge with <code>--no-ff</code> once everything is done. With nested branches, I do the same: multiple branches are merged sequentially onto the main branch, which is itself merged to master in the end.</p>
  
  <p>In order to keep information about merges with nested branches, I often use <code>git rebase --preserve-merges</code>. This does exactly what I want and I have no problems with my workflow.</p>
  
  <p>My main problem with git is that <code>git rebase --preserve-merges</code> is very slow (sometimes taking about 2 seconds per commit). After reading <a href="https://stackoverflow.com/questions/15915430/what-exactly-does-gits-rebase-preserve-merges-do-and-why">What exactly does git&#39;s &quot;rebase --preserve-merges&quot; do (and why?)</a> I realize that git must perform a lot of work to preserve the merges, since git has to work on arbitrary graphs.</p>
  
  <p>What I was wondering is this: since my workflow pretty much results in a graph equivalent to a linear history, is there a way to perform a <code>git rebase --preserve-merge</code> equivalent in a faster way, given that I guarantee "linearity" of history with only empty merge commits? I don't mind using scripts or weird commands, as long as the final result is correct.</p>
  
  <pre><code>     A-B-C
      /     \   
  (1)--------D-- master
      \
       \---F-----I-- feature
        \ / \   /
         E   G-H
  
       A-B-C   E   G-H
      /     \ / \ /   \
  (2)--------D---F-----I-feature
           master
  </code></pre>
  
  <p><strong>tl; dr:</strong> How to transform (1) into (2) knowing that the underlying history is linear so <code>git rebase --preserve-merges</code> doesn't have to do as much work and does it fast?</p>