Presenting a clean history: how to synchronize two repositories.

[Michael McNeil Forbes]

On May 13, 2014, at 12:43 PM, Harvey Chapman <hchapman-hg at 3gfp.com> wrote:
> On May 13, 2014, at 3:10 PM, Michael McNeil Forbes <michael.forbes at gmail.com> wrote:
>> 
>> 1) It is hard to learn about the history of the dirty project since there are
>>  thousands of revisions (especially for a student or new collaborator).  I
>>  would like a clean version of the repo as a pedagogical tool.  One possible
>>  option for this would be a way of "tagging" (not tags though) certain change
>>  sets so that that hg provides a simple overview of the repo via only those
>>  tagged changesets (collapsing the intermediate steps as needed, and showing
>>  only diffs between the tagged changesets etc.) I.e. some sort of metadata
>>  documenting the clean path through the repo but without actually editing
>>  history.
>> 2) By mistake, we added too much to the repo.  I would like to strip out of
>>  bunch of stuff, and publish a cleaned version for the public at large to use
>>  (rather than just our core team which will probably stay working on the old
>>  repo with everything.
> 
> The method I had thought to use involved maintaining a separate, “abridged” branch in your dev repo for public exposure. You can use the fold command to collapse lots of little checkins into milestones or features. To accept patches or move things back and forth, you can graft or transplant changesets. Then, you only publish the abridged branch.

How would one publish only the abridged branch?  If it derives from the dev repo, won't it by necessity required the entire dev repo since the changeset hashes are based on the entire history?

Unless you mean use convert as I suggested, in which case I am then looking for some people with experience doing this so I understand the potential pitfalls, and how to implement the grafting/etc. across the two repos.

Michael.