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?). Also, the other 4 should have no parent, otherwise you've not cut-off any history. > > 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. Michael -- 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