<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, May 23, 2013 at 5:49 AM, Eli Barzilay <span dir="ltr"><<a href="mailto:eli@barzilay.org" target="_blank">eli@barzilay.org</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">9 hours ago, Carl Eastlund wrote:<br> > I was going to comment on the same thing. While a naive use of "git<br> > filter-branch" might not retain the history, it should be entirely<br> > possible to do something a little more intelligent and keep that<br> > history.<br> <br> </div>Just to be clear, this is exactly what you can't get with<br> filter-branch.<br> <div class="im"><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> </div>This can work, but it is unrelated to filter-branch: it's basically<br> starting each package repository from a clone of the monolithic repo,<br> then move & shuffle things around.<br> <br> This seems wrong to me in all kinds of ways -- but if someone wants to<br> do this with *their* package (ie, not a package that I need to deal<br> with), then it's certainly an option.<br></blockquote><div><br></div><div>It doesn't seem wrong to me. It's an accurate representation of the history of the project, which is exactly what git is for retaining. Where does the problem come from? If git filter-branch doesn't maintain the history we need, it's not the right tool for the job.<br> <br></div></div>--Carl<br></div></div>