Hidden Commits in 4.3

[Ryan McElroy]

On 4/5/17 12:06 PM, Pierre-Yves David wrote:
> On 04/05/2017 03:11 AM, Durham Goode wrote:
>> There's been a lot of discussion about how to hide and unhide commits
>> lately [0][1], and I feel the complexity of our current approach is
>> hurting our ability to reason about it, making it impossible to make
>> progress.
>>
>> I would like to formally propose a new pattern for dealing with hidden
>> commits, along with the concrete steps to getting it enabled in core by
>> default by the August release.
>>
>> The proposal is quite concise, so check out this 1-page Google doc for
>> the details and to comment:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__goo.gl_7DJ9AI&d=DwICaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=Jw8rundaE7TbmqBYd1txIQ&m=_EDBw1CsTCN9AalNXSST2Y62jINxpEATYeSxmKe5Brw&s=lcEiWk2_jcVL_lnSZF-y7QwHxlG_0__q7hK-SigQqm4&e= 
>>
>> If people find this approach promising, I can commit to trying to get
>> this upstream by the August release. So if you have questions or
>> concerns, please let me know so I can address them.
>
> Thanks for writing this proposal.
>
> The change proposed to evolution is problematic. As explain in my 
> reply to the other thread[1], at minimum, removing the link between 
> obsolescence and visibility is destroying the "global-state" property 
> we currently have. This put in disarray the whole ability to use 
> evolution to exchange and collaborate on mutable history, the very 
> thing evolution has been built for. I've not seen strong-enough 
> rationals for derailing the current evolution plan and design.

I agree that the hiding proposal should focus on hiding instead of 
changes to evolution/obsolescence. We should be able to get the former 
without any changes to the latter.

>
> I think we really needs to take a step back here. Before thinking 
> about unification, I think we needs a clean definition of what we are 
> doing here. As mentioned in another thread[2], they are at least three 
> identified categories of things we want to hide. obsolete, internal, 
> and some local only hiding. The first two are quite well defined now, 
> the last one less so.

I disagree. I don't think we need to understand all the ways that things 
might be hidden before coming up with a good way to hide things that 
core hg and extensions can use in whatever way they wish. Generic hiding 
allows the deeply needed improvements to core hg the Greg described in 
the other thread, without waiting for evolve to be complete (which is 
still a ways off).

>
> I think we should currently refocus the discussion on the local-only 
> hiding. What are its usecases, what are the wished behavior. A large 
> part of what Durham just wrote can directly be re-used for that. But 
> re-centered on the local usecase, with the changes to evolution core 
> behavior.

No, please let's not require solving a potential use case before 
building the mechanism that will allow us to build use cases we already 
know we want and need.

>
> Once we have a clear view of the three concepts usecase, behavior and 
> constraint we can start looking for synergy between them.

We already know the synergy -- we want ways to hide things. Let's build 
that and let each new concept use it in appropriate ways without trying 
to solve every potential problem first. Everybody wants hiding. So let's 
add generic hiding that can be exposed in various ways, including by evolve.

>
> Cheers,
>
> [1] 
> https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096239.html