<div dir="ltr">On Thu, May 23, 2013 at 6:57 AM, Eli Barzilay <span dir="ltr"><<a href="mailto:eli@barzilay.org" target="_blank">eli@barzilay.org</a>></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="HOEnZb"><div class="h5">A few minutes ago, Carl Eastlund wrote:<br>
> On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay <<a href="mailto:eli@barzilay.org">eli@barzilay.org</a>> wrote:<br>
><br>
> 9 hours ago, Carl Eastlund wrote:<br>
> > I was going to comment on the same thing. While a naive use<br>
> > of "git filter-branch" might not retain the history, it should<br>
> > be entirely possible to do something a little more intelligent<br>
> > and keep that history.<br>
><br>
> Just to be clear, this is exactly what you can't get with<br>
> filter-branch.<br>
><br>
> > Essentially each of the new repositories could keep the entire<br>
> > history of the original repository, followed by a massive<br>
> > move/rename, then moving forward with an individual package.<br>
><br>
> This can work, but it is unrelated to filter-branch: it's<br>
> basically starting each package repository from a clone of the<br>
> monolithic repo, then move & shuffle things around.<br>
><br>
> This seems wrong to me in all kinds of ways -- but if someone<br>
> wants to do this with *their* package (ie, not a package that I<br>
> need to deal with), then it's certainly an option.<br>
><br>
> It doesn't seem wrong to me. It's an accurate representation of the<br>
> history of the project, which is exactly what git is for retaining. <br>
> Where does the problem come from?<br>
<br>
</div></div>The problem of filter-branch? It has no problems, it does exactly<br>
what it is supposed to do.<br></blockquote><div><br></div><div>It has "no problems"? Where above you stated "this is exactly what you can't get with filter-branch" in reference to keeping our packages' relevant history. That sounds like a problem to me, in our current context.<br>
<br>But filter-branch is not what I was talking about. I was talking about _not_ using filter-branch, and instead doing something that does keep history.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> If git filter-branch doesn't maintain the history we need, it's not<br>
> the right tool for the job.<br>
<br>
</div>If the drracket files are irrelevant for the swindle package then they<br>
shouldn't be in the swindle repository -- and on the exact same token,<br>
the development history of drracket shouldn't be there either.<br>
<br>
(This is not new, BTW, I think that there was general concensus right<br>
from the start of the package talk that the monolithic repo is just a<br>
host for a bunch of separate projects.)<br></blockquote><div><br></div><div>Okay, then let's purge the history of irrelevant files, but keep the history of relevant files even if they weren't in the "right" directory. If the monolithic repo is just a host for a bunch of separate projects, shouldn't it be possible to tease out their more-or-less separate histories?<br>
</div><div> </div>--Carl<br></div></div></div>