Hidden Commits in 4.3

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed Apr 5 11:06:04 UTC 2017


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://goo.gl/7DJ9AI
>
> 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 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 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.

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

Cheers,

[1] 
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096239.html
[2] 
https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/095932.html

-- 
Pierre-Yves David



More information about the Mercurial-devel mailing list