On Thu, Nov 25, 2010 at 3:37 AM, Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> wrote: > Cory Fields venit, vidit, dixit 24.11.2010 05:33: >> I am having some trouble understanding how a replaced object (commit) >> should behave when pushed to a remote repo. Here's my scenario: >> >> We are moving from svn to git. Our svn repo is huge, and most of the >> history is useless. To save space, I would like to do a 50/50 split so >> that when the repo is cloned, 50% is seen by default, and the >> historical 50% can be seen by fetching the replacement history. I've >> done this by creating a phony snapshot at 3 then using a 'replace' to >> put the others on top. The history is purely linear. >> >> 1---2---3---4---5 >> Â Â Â Â Â Â Â Â Â\---4---5 > > I assume the "other" 4 goes off 3 (you're not using a monospaced font, > are you?). > I used a monospace font, but gmail decided not to use it. Sorry for that. > Also, the other 4 should have no parent, otherwise you've not cut-off > any history. I created a "fake" 4 that consists of the full working tree at 4 with no parent. As I mentioned, everything looks fine locally. > >> >> When the replacement is in place, the repo is half size (commit-wise) >> as expected. The problem is that 'git push' does not honor the >> replace. So when I push, all objects go with it, which defeats the >> purpose. The only way that seams to work is doing a filter-branch and >> replacing the other way. >> >> Is this by design? I would really like a way to split the repo without >> breaking hashes for the developers that have already begun using git >> svn. > > It is by design since a replace creates a "fake history", and this > should not be created behind a users back. > > The 5 is not rewritten, and it's ancestry contains the whole history. If > that is the commit your developers have already and that you want to > preserve then there's not much you can do. > > You could try to push or pull your replacement refs first (refs/replace) > but I don't think this will change what objects the push of 5 will > transfer. Just have a try. I tried this to no avail. I realize that allowing replacements to be pushed "behind users backs", so I guess not respecting it makes sense. But is there no way that I can pull this off without rewriting hashes? Thanks, Cory -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html