question about fold

[Simon King]

On Thu, Apr 2, 2015 at 2:49 PM, Neal Becker <ndbecker2 at gmail.com> wrote:
> Augie Fackler wrote:
>
>> On Thu, Apr 2, 2015 at 9:19 AM, Neal Becker <ndbecker2 at gmail.com> wrote:
>>> This morning I copied some of my updates from machine 1 to machine 2.
>>> Everything was built fine on m1, so I pulled the update to m2.  But it
>>> didn't build on m2.  I had forgotten to add/ci some files.  So I fixed
>>> that on m1 and pulled to m2.
>>>
>>> So this would seem like a perfect use for fold.  Now I have 2 different
>>> commits, the first says:
>>>
>>> added feature foo
>>>
>>> and 2nd says:
>>>
>>> more foo
>>>
>>> or something to that effect.
>>>
>>> But I can't use fold, because fold refused to operate on 'public' repos.
>>>
>>> So finally, here is my question.  Is this restriction necessary, or could
>>> it
>>> be eventually removed?  Just wondering.
>>
>> This is intentional, as part of a plan to prevent accidentally
>> modifying history that you've published to others. If you add
>>
>> [phases]
>> publish = false
>>
>> to ~/.hgrc, then those machines won't be considered to have
>> "published" changes when they serve them to other clients. Does that
>> make sense?
>>
>
> Somehow this doesn't feel all that useful to me.  For my own use, I doubt
> I'd be marking repos as experimental apriori.  I'm always ready to believe
> my changes are finished, except when I find out they're not.
>
>> (We know this is complicated and slightly annoying - improving it is
>> on the agenda eventually.)
>>
>> For the present day problem, you can probably do 'hg phase --force
>> --draft' on the changes that shouldn't be marked public and then
>> you'll be able to edit them.
>>
>
> And where machine2 pulls those changes, it won't complain?  For example, it
> won't care about the change in phase after having already pulled the 1st
> change, correct?
>

machine2 won't change the phase of those changesets back to draft. As
far as I'm aware, the only way to "reduce" the phase of a changeset is
via "hg phase --force".

In fact, machine2 will still have the original 2 changesets, and it
will also get the new folded changeset, so you'll have a multi-headed
repository. This is exactly why editing history on changesets that
have been transferred to another repository is blocked by default -
there is no way for other repositories to know that a changeset has
been replaced.

The Changeset Evolution project
(http://mercurial.selenic.com/wiki/ChangesetEvolution) has added a new
facility to mercurial which will improve this in the future. With
these features enabled, when you fold 2 changesets together, the
resulting changeset will be marked as a successor of the 2 originals.
These markers are transferred between repositories on push and pull.
The end result is that when you pull on machine2, it will know that
the new folded changeset replaces the two originals.

Hope that helps,

Simon