<div dir="ltr">On Wed, May 22, 2013 at 8:21 PM, Matthew Flatt <span dir="ltr">&lt;<a href="mailto:mflatt@cs.utah.edu" target="_blank">mflatt@cs.utah.edu</a>&gt;</span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">At Wed, 22 May 2013 14:50:41 -0400, Eli Barzilay wrote:<br>
&gt; That&#39;s true, but the downside of changing the structure and having<br>
&gt; files and directories move post structure change will completely<br>
&gt; destroy the relevant edit history of the files, since it will not be<br>
&gt; carried over to the repos once it&#39;s split.<br>
<br>
</div>It&#39;s possible that we&#39;re talking past each other due to me not getting<br>
this point.<br>
<br>
Why is it not possible to carry over history?<br>
<br>
The history I want corresponds to `git log --follow&#39; on each of the<br>
files that end up in a repository. I&#39;m pretty sure that such a history<br>
of commits can be generated for any given set of files, even if no<br>
ready-made tool exists already (i.e., &#39;git&#39; is plenty flexible that I<br>
can script it myself).<br>
<br>
Or maybe I&#39;m missing some larger reason?<br></blockquote></div><br></div><div class="gmail_extra">I was going to comment on the same thing.  While a naive use of &quot;git filter-branch&quot; might not retain the history, it should be entirely possible to do something a little more intelligent and keep that history.  Essentially each of the new repositories could keep the entire history of the original repository, followed by a massive move/rename, then moving forward with an individual package.<br>

<br></div><div class="gmail_extra">--Carl<br></div></div>