Internal-changeset concept

[Pierre-Yves David]

(the most interesting content, directly about the internal-concept, is 
at the end of this email)

On 04/05/2017 03:23 PM, Ryan McElroy wrote:
> On 4/5/17 11:40 AM, Ryan McElroy wrote:
>> […]
>> (3) Thanks to Pierre-Yves for the detailed analysis of verious
>> mechanisms for implementing internal-only changesets. This is super
>> valuable, especially the parts about why a changeset marker alone is
>> insufficient, and the analysis of the work involved to implement
>> various ideas. You went way above and beyond what my question was
>> intended to solicit. I was honestly just looking for something like
>> "yeah, I've thought about this and I think phases could work" or "I
>> think phases won't work because of this problem" -- but you wrote up a
>> design doc! Amazing.

o:-)

Giving a proper answer to your question actually required me to go 
through the whole thinking process. Writing it down has overhead is 
helping with the thinking too. Once I've a fully formed Idea on my head 
I can as whole preserve it for other before it become fuzzy again.

As we discussed through another channel, I could have answered:

   "My guts feeling is that we found a case were phases would work"

and I almost did. But by the time I got in front on a computer to write 
it, the train of thoughts was already half way there. I was happy enough 
to have found a a potential valid new phase that I did the whole 
journey. ¯\_(ツ)_/¯

>> (4) In response to the design proposal, I agree that it feels
>> over-complicated to me for what I would be trying to accomplish with
>> the feature. I agree with Jun that we can use "dynamic unhiding" for
>> finding the changesets we're interested in, so I don't think we need
>> two new phases, and I think that losing the strict ordering of phases
>> would be too much pain to introduce for this feature. So, my proposal
>> would be a single phase just above "secret" called "internal" that,
>> like secret, would never be exchanged, and would be hidden by default
>> (unless dynamically unhidden via being checked out or directly
>> accessed, for example). I'm against forbidding the user to do things
>> with this changeset -- I always opt to let the user do things, in
>> general, that they ask to do. If they want or run diff or update or
>> whatever to it, sure, let them. The nice thing about having a generic
>> hiding mechanism [item (2) above] is that we don't have to worry about
>> the details of how things are hidden. Overall, I think having a
>> "default hidden phase that doesn't get exchanged like secret" would
>> get us everything we want, and we don't need to introduce new flags or
>> hard concepts into phases. It's just another phase.
>
> Re-reading this, I think it might be confusing that I'm suggesting this
> phase be a generic way to hide things. I'm not. To be clear, I'm
> proposing this new phase as a possible user of the generic hiding system
> -- and only as a way to give shelve (and things like shelve -- eg,
> amend) a non-stripping, non-obsmarker path forward.

If I understand you correctly, what you describe above overall match the 
current state of the plan page. So we seems overall in agreement here.

> Still, see below. I think it's worth shelving this until we have a
> generic hiding system.

Actually, we already have a generic hiding mechanism. For the past 4 
years.  In order to cut some heads of this threads hydra, please see and 
comment on my extended reply here.

https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096294.html

Cheers,

-- 
Pierre-Yves David