pierre-yves.david at ens-lyon.org
Wed Apr 5 19:04:30 EDT 2017
(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.
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
>> (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.
More information about the Mercurial-devel