Presenting a clean history: how to synchronize two repositories.

[Harvey Chapman]

On May 13, 2014, at 11:08 PM, Michael McNeil Forbes <michael.forbes at gmail.com> wrote:

> 
> On May 13, 2014, at 7:42 PM, Harvey Chapman <hchapman-hg at 3gfp.com> wrote:
>> On May 13, 2014, at 4:14 PM, Michael McNeil Forbes <michael.forbes at gmail.com> wrote:
>>> 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:
>>>>> 
>>>> 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.
>> 
>> The branches are basically unrelated in terms of the DAG so pushing just the abridged branch doesn’t require the dev branch to be pushed. It’s like your convert solution I think, but probably easier to manage.
> 
> I must be missing your idea: if I create an "abridged" branch and then when I merge in changes from the dev branch, the "abridged" branch will depend on the dev branches: there is no way of not pushing everything.

You’ll never merge anything between the two branches. They might as well be separate, unrelated repositories. You only keep them in one repository for ease of use.

> Perhaps you suggest that the "abridged" branch have nothing merged in from the dev branches, then I could push as you suggest, but there is no information about which changesets in the dev branch correspond to which changes in the abridged branch: hence there is no easy way of coordinating the flow of information back and forth.

You could use a bookmark, local tag, or even a branch head to track the changeset in DEV that is equivalent to the head of ABRIDGED. Then occasionally, you graft the changesets abridged_tip_on_dev_bookmark::some_point_forward_on_DEV onto ABRIDGED. Then you do whatever cleanup (fold, etc.) you desire on the newly grafted changesets before pushing ABRIDGED up to your public repository. Finally, update abridged_tip_on_dev_bookmark to some_point_forward_on_DEV.

> It seems that at least with convert, there is some sort of mechanism for the converted repo to keep track of which changesets each part of the converted repository came from.  I am looking for advice on how to actually use this information in a sane manner.

I think the problem with convert is that the hashes for the same changesets can be different after two different runs of the same conversion. I may be wrong about that, though.

Harvey