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