On Fri, Nov 26, 2010 at 8:58 PM, Cory Fields <FOSS@xxxxxxxxxxxxxxxxxxxxxxxx> wrote: > On Fri, Nov 26, 2010 at 6:18 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> Jonathan Nieder <jrnieder@xxxxxxxxx> writes: >> >>> ÂReal history >>> Â------------ >>> Â4' --- 5 --- 6 >>> >>> Â1 --- 2 --- 3 --- 4 >>> >>> ÂFake history >>> Â------------ >>> Â1 --- 2 --- 3 --- 4 --- 5 --- 6 >>> >>> ÂReplacement ref >>> Â--------------- >>> Â4' --> 4 >>> >>> This way, a person a person can fetch either piece of real history >>> without trouble, and if they fetch the replacement ref, too, the >>> history is pasted together. >>> >>> It is not possible in git to push a commit without its ancestors; >>> replacement refs do not change that. >> >> True, but I suspect the above picture pretty much satisfies Cory's initial >> wish, no? ÂYou can fetch recent 4'--5---6 history as if 4' were the root >> commit, and if you fetched replacement that tells us to pretend that 4' >> has 3 as its parent (and the history leading to 3), you will get a deeper >> history. >> > > Yes, both of these can be accomplished. I've managed to get that part > working, where a > default clone pulls in half history, and fetching refs/replace gives > you the rest. The only > problem is that it requires a filter-branch before pushing. Otherwise, > 4 gets pushed rather > than 4', meaning that clones will require all the objects. So it > works, but I'll have to spend > quite a while making it 'perfect' so that I only have to rewrite history once. > > A shallow clone does not fit for us, because we want the default clone > to only pull half. > Having a public 1gb repository that will be cloned quite often is > bound to make our host > unhappy, so we're doing everything we can to get the size down. > > Also, maybe I haven't made this clear... the "real" commit IDs need to > match the "fake" > ones in order to prevent confusion. I think that's the part that makes > this so difficult. > Otherwise, something like this [1] would work just fine (probably > exactly what Junio was > suggesting) > > Any other suggestions? Or do I just have to face the fact that I'm > going to have to break > hashes? > > [1] http://progit.org/2010/03/17/replace.html > > Cory > Sorry for the stupid wrapping.. gmail and I are not getting along in this thread! 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