tags:

views:

39

answers:

1

I am in the midst of doing some non-standard, probably doomed, experiments on a git repository. The goal is to create a remote repository with a truncated history which can still share commits with an internal repository which has a full history.

I've had some success using a graft to connect the public history with the private history - when I push from my internal repository, only the post-graft contents are included.

So my main question is: what is the simplest way of taking a commit, eliminating its parent and writing a graft in place of the parent?

A more general question: is what I'm trying to do going to cause me pain in the long run, do you know if there's a better way?

A: 

Scott Chacon talks about something similar to what you're describing in a recent Pro Git post. He uses git rebase --onto to separate the history into two parts, later showing how to use git replace to restore the history later, should you want to do so. I've never done this myself, but it's explained in great detail in his post. Lots of diagrams too.

MikeSep