On 4/5/17 4:06 AM, 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=nuarHzhP1wi1T9iURRCj1A&m=Yj1C1AtQvsolF0hlwM1JkxxKSLbV6vXg7DoMNDxaG1M&s=Ek8tm4MPVTL8WZOf4TuwRANa0lR_mzze8jCT5MdvXTk&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.
The simpler implementation model, the simpler mental model, the simpler
ability for commands to use hiding, and the lack of tie-in with other
more divisive features is the reason for this proposal. With this
proposal we can have the majority of the benefits quickly, without
notable changes to the existing core UI, and in a intuitive form for users.
I believe these benefits outweigh the downside to evolve's current goal,
in particular since the actual end experience of evolve is still under
discussion.
I think other members of the community would have to weigh in on whether
this trade off is worth it, since it is a subjective decision.
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.
Others should chime in here. I think this proposal is the step back and
provides a clean definition of what hiding is and a unified approach
that can be applied intuitively to hiding needs.
Even the current obsolete-markers-cause-things-to-be-hidden
functionality could be implemented on top of this, if we wanted it to.
We just gain the ability for users to unhide those commits if they want,
which I think is an improvement for the user experience.
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.
I agree with Ryan here. I think the use case here is already clear: we
want the ability to hide and unhide commits. This proposal will let us
experiment with use cases more freely, and we should not limit the
discussion here to avoid affecting existing behavior, nor delve down
rabbit holes when there's a simple unified proposal that many people
seem satisfied with.
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
