Making "hg push -r foo" changes phases

[Angel Ezquerra]

On Mon, Jun 17, 2013 at 8:29 PM, Jordi Gutiérrez Hermoso
<jordigh at octave.org> wrote:
> On 17 June 2013 14:23, Angel Ezquerra <angel.ezquerra at gmail.com> wrote:
>> On Mon, Jun 17, 2013 at 6:37 PM, Jordi Gutiérrez Hermoso
>> <jordigh at octave.org> wrote:
>>> On 17 June 2013 12:32, Angel Ezquerra <angel.ezquerra at gmail.com> wrote:
>>>> On Mon, Jun 17, 2013 at 6:19 PM, Jordi Gutiérrez Hermoso
>>>> <jordigh at octave.org> wrote:
>>>
>>>>> The reason why draft->secret requires a force is that drafts can be
>>>>> shared between non-publishing repos. It's a kind of sharing that isn't
>>>>> as widespread as a public repo, but it's still sharing. If you push a
>>>>> secret phase to a non-publishing repo, it is now a draft, and it
>>>>> should stay this way.
>>>>
>>>> I don't think that is a very strong reason to require a --force option
>>>> for the draft-secret phase transition.
>>>>
>>>> It is true that draft revisions can be shared, but they are still
>>>> mutable. Making a public changeset draft is dangerous because then
>>>> mercurial will let you modify it (e.g. though amend, etc) where you
>>>> could not modify it when it was public. Making a draft revision secret
>>>> does not let you do things that you could not do before since draft
>>>> revisions are already mutable.
>>>
>>> There are two things that phases indicate: (1) should this commit be
>>> pushed? (2) should this commit be modifiable? Once a commit is already
>>> shareable, e.g. after it's already been shared, then to paraphrase
>>> 4chan, "what has been shared cannot be easily unshared." The force
>>> here is there to indicate that we cannot easily unshare. It's part of
>>> the whole point of phases.
>>
>> When you push to a non publishing repo, you do not expect a draft
>> revision to remain immutable.
>>
>> In a way, you could say that one of the main reasons for the the
>> changeset evolution work that has been going on for the past few
>> releases (and of which phases is one of the foundations) is to be able
>> to make the sentence "what has been shared cannot be easily unshared."
>> false :-)
>>
>> Or at least that is my interpretation.
>
> You are again conflating sharing and changing. These are two different
> things. They are related, which is why we only have three phases, not
> four (i.e. not all possible combinations of
> shared/unshared+modifiable/unmodifiable).

I don't think I'm conflating sharing and changing. I think the phases
concept does (for a reason). On one hand phases indicate mutability
(public vs other phases). On the other phases indicate if revisions
cannot be / could be / have been shared (secret vs draft vs public).

It would be really nice if we had a mechanism to tell, not only if a
given revision has been shared, but with whom a given revision has
been shared to or from. We discussed this a bit during the London
sprint. I thought that it would be nice to have a fourth phase, called
"shared", between public and draft (which would make this whole
discussion moot). I think it was Kevin or Pierre-Yves who made the
very good point that it would be best to have some additional,
detailed metadata that could tell you with whom a revision had been
shared.

> Secret phases are about whether things should be shared or not, not
> about whether they should be modified or not. Once a revision has been
> shared, changing a draft revision back to the secret phase is
> potentially a kind of lie, unless the locations in which it's been
> shared are scrubbed.

I disagree. Would you say that stripping a shared public changeset is
also a form of lie? As long as I you are not changing a revision, the
fact that I mark it secret or I strip it does not change history. It
just makes history incomplete from my point of view (in the case of
strip) or from the point of view of whoever I share my history with
later on (in the case of a draft to secret phase transition).

> The evolve extension is about collaboratively editing draft commits.
> Not about making  sure that you don't publish commits you don't want
> to publish.

My point was that the evolve extension makes the old "shared history
is sacred" adage not apply anymore, under certain circumstances.

Anyway, coming back to the original subject, I don't feel super
strongly against requiring the use of --force to move from draft to
secret. There are some (rare) cases where it may be a bit dangerous
(specially when using subrepos). But I do think that it discourages
the usage of secret changesets a bit, which is a pity.

It is also a bit inconsistent. For example, we can turn a draft
revision secret without a --force option by means of the mq extension
(which has an option that automatically turns patches secret).

I also think that a lot of people (me included) had been using the
public phase as a way to tell which revisions had been shared. This
model breaks down once non publishing repos and the evolve extension
come into play. I think that is a pity, and I'd like to have a more
reliable mechanism to tell what has been shared with whom. Something
that goes beyond what phases can provide as they are today.

Cheers,

Angel