Hidden Commits in 4.3

[Martin von Zweigbergk]

On Wed, Apr 5, 2017 at 3:02 PM, Durham Goode <durham at fb.com> wrote:
> 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.

As I said before, I like the proposal. I would be happy to have a more
thorough discussion of how various use cases would work out with your
proposal, though. The arguments I have seen have been too abstract for
me to really care about. I like more concrete points about what will
and will not work. The other arguments are just skim over and forget.
Maybe others like the abstract arguments better, so feel free to
ignore me if I'm the exception here.

>
>> 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.