OK.  Sounds we should make this setup default.  I&#39;ll see if we can&#39;t educate update-webkit and webkitpy/common/checkout/scm.py about detecting this setup and doing the right thing in that case.<div><br></div><div>I&#39;ll file a separate bug about making scm.py&#39;s Git object use --no-rebase during dcommit.</div>
<div><br></div><div>-eric<br><br><div class="gmail_quote">On Thu, Nov 18, 2010 at 4:08 PM, Evan Martin <span dir="ltr">&lt;<a href="mailto:evan@chromium.org">evan@chromium.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Nov 18, 2010 at 3:36 PM, David Levin &lt;<a href="mailto:levin@google.com">levin@google.com</a>&gt; wrote:<br>
</div><div class="im">&gt;&gt; It&#39;s some magical setup by which your git svn fetchs will be much faser.<br>
&gt;&gt;  But I&#39;ve heard it&#39;s buggy?  Can lead to local repository corruption?<br>
&gt;&gt; Can someone set me straight?<br>
<br>
</div>No magic, just standard git: complicated, but logical once you<br>
understand how it works. :\<br>
<br>
It means that both &quot;git pull&quot; and &quot;git svn fetch&quot; will be updating the<br>
same branch.  When the latter sees the former has pulled down new<br>
stuff (quickly, via the fast git protocol), it knows to rebuild its<br>
metadata from the new stuff you fetched (rather than fetching it all<br>
over again via the slow svn protocol).<br>
<br>
There&#39;s a catch: if you &quot;git svn fetch&quot;, that creates new commits<br>
locally.  When you later &quot;git pull&quot;, you get the commits that were<br>
constructed by <a href="http://git.webkit.org" target="_blank">git.webkit.org</a>, which don&#39;t match (due to differing<br>
timestamps).  This may screw up rebase, but I believe it&#39;s smart<br>
enough to recognize the commits are &quot;the same&quot; (applied the same diff;<br>
in git jargon, they have the same patch-id).  In practice you don&#39;t<br>
even run &quot;git svn fetch&quot; except when the git server is behind, so I<br>
don&#39;t know if there are corner cases here that I haven&#39;t run into.  (I<br>
also haven&#39;t tried this on Windows in a while -- kind of terrified of<br>
git there, though I hear it works for others.)<br>
<br>
In particular for bots that are not committing, I see no catch, other<br>
than that they will be behind whenever <a href="http://git.webkit.org" target="_blank">git.webkit.org</a> is behind.<br>
<div class="im"><br>
&gt;&gt; The current git svn fetch is *super* slow.  Especially if you&#39;re behind by<br>
&gt;&gt; more than a day or two.<br>
&gt;&gt; If there was a way to make this faster method safe, by wrapping it in some<br>
&gt;&gt; other (error-checking) command which knew how to fall back to git svn<br>
&gt;&gt; rebase, etc. when necessary I would love to make it the default method for<br>
&gt;&gt; all WebKit get users.<br>
<br>
</div>I have instructed all Chrome git users to use this method since<br>
(checking the commit history...) Feb 2009 and it seems to work for us.<br>
 Note that you need git &gt;= 1.6.1 or so for it to work properly.  I<br>
also use this method for working on WebKit (though I&#39;ve only committed<br>
around 60 patches so I mostly use it for pulling down new code).<br>
<br>
PS: our tools also run svn dcommit with &quot;--no-rebase&quot; to avoid<br>
needlessly going out to svn again after committing.<br>
</blockquote></div><br></div>