On Wed, Dec 09, 2015 at 02:45:44PM +0100, Jörn Hees wrote: > I've been hacking away on a library for quite some time and have a lot of commits in my private repository: > > A -> B -> C -> D -> E > > Finally, I'm nearing completion of a first version, and want to > publish it to a remote called public from D onward keeping A..C to > myself, so public should afterwards look like this: > > D -> E The short answer is that you cannot do this without changing the names (i.e., sha1 commit ids) of D and E. One of the fundamental assumptions git makes is that if a repository has an object X, it also has all of the objects reachable from it (past commits, their trees, subtrees, and blobs). This is what makes the push/fetch object transfer efficient (one side says only "I have X" and the other side knows "Ah, that is a whole chunk of objects I do not have to bother sending", without the names of those objects going over the wire). The exception, of course, is shallow clones, where one side tells the other "I am shallow at cutoff point Y; don't assume I have anything below there". This does work, but there are some downsides (for instance, we cannot apply some of the same reachability optimizations for serving fetches). > I can verify that local_public only contains D -> E and that the > commit, tree and parent hashes are the same, which is exactly what i > want. > > The problem is that when i try to push to an added public remote > from local_public i get an error like this: > > ! [remote rejected] master -> master (shallow update not allowed) Right. The receiver must be explicitly configured to accept a shallow push (I do not recall offhand whether clients fetching from you would also need an explicit config to accept a shallow history). So the usual path here is to rewrite D and E (with the same trees, but they will get new commit ids). If you want to retain the older history (commits A-C), you can distribute it separately and use git-replace to "graft" it onto the newer history at run-time. You can do that with: # set up a run-time replacement view so that D appears to have # no parents; this doesn't impact the objects themselves, but # rather git will use our parent-less "replacement" D anytime # somebody mentions the original git replace --graft D # verify that the history is what you want; if you have a non-linear # history you may have to make several such "cuts" in the graph git log # now cement it into place by rewriting git filter-branch Of course that is a bitter pill to swallow if you have reasons for wanting to use the old sha1s. E.g., you have internal development proceeding against the old tree and want to share a truncated version with the public. In that case I still think the least painful thing is to rewrite the truncated history, have _everyone_, internal and public work against that, and let internal folks graft the old history on for their own use. They can do that with: git replace --graft the-rewritten-D the-original-C -Peff -- 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