Hidden Commits in 4.3

Pierre-Yves David pierre-yves.david at ens-lyon.org
Fri Apr 21 14:17:22 EDT 2017


note: I recommend people interrested in this discussion to subscribe to 
the related wiki pages:

https://www.mercurial-scm.org/wiki/CategoryEvolution
https://www.mercurial-scm.org/wiki/HideUnhidePlan

On 04/14/2017 01:12 AM, Durham Goode wrote:
>
>
> On 4/13/17 2:43 PM, Pierre-Yves David wrote:
>>
>>
>> On 04/13/2017 11:37 PM, Pierre-Yves David wrote:
>>> On 04/12/2017 04:23 PM, Ryan McElroy wrote:
>>>> I think the next step is for the community to officially figure out
>>>> if this is a good direction to go in, however that happens.
>>>
>>> I had productive face to face discussion with multiple people in the
>>> past couple a day.  Let us put all technical details aside and look at
>>> the situation at the high level.
>>>
>>> The current tentacular discussions are the *gathering of three
>>> different goals*:
>>
>> There a was a secondary point I wanted to make. But I did not wanted to
>> inflate the the size of the previous email too much.
>>
>> The recent discussion *mixes multiple complex topics*. Complex both at
>> the technical and UI level. It results in a *back and forth of
>> interleaved discussion* *with people caring about different aspects*.
>>
>> As a good symptom of that, I've read maybe 3 summaries of the situation
>> and existing consensus by three different people in the last 48h. To me
>> they seems to reach sightly different conclusions and outline different
>> consensus. I'm not even sure how to interpret some ambiguity in them.
>>
>> After discussion this further with Gregory, I think *we really needs to
>> introduce more focus this discussion*. I know everybody are itching to
>> bring up some topics, but we should agree on what is the *next most
>> important small step we can take and focus on that*. Without trying to
>> alter other aspects in the same go. Having a*small group of neutral
>> moderators* to lead the discussion would help.
>>
>> From the current state of the discussion, I think we should starts with
>> a *restricted discussion about an alternative to strip*, /mutually
>> exclusive with evolution/. I personally though local-hiding and
>> obsolescence hiding could coexist until I read Gregory email. He seems
>> to be raising valid concerns there.  When that topic is sorted out, we
>> can move the discussion to something else, for example how they could
>> coexist.
>>
>> What do you think?
>
> If we delete the "Interaction With Obsmarkers" paragraph of my proposal,
> it's effectively a proposal for an alternative to strip. Would that be
> an appropriate starting place for a alternative-to-strip discussion?  We
> could leave out it's interaction with evolve for now.

(Yes, I'll look at Jun email shortly, but I had this draft 80% written 
and it can help define a smooth way forward, so I polished and sent it).

Focusing on a simple replacement for strip would probably be a good 
start and your proposal provides a good base for that. However we needs 
a deeper path at the proposed UI and behavior.

When I was chatting with Gregory Szorc, he highlighted that solution we 
ship earlier should had a "good compatibility story" for the time we 
ship completed changeset evolution. Some part of the proposal are 
currently unclear to me in that regard (eg: unhiding mechanism/command)

On a general basis, we needs to design a UI where user can reach new 
features with a reasonable amount of complexity (in regard with the 
feature reached). Lets take an example of a user slowly using more and 
more of the features,

1) making commit,
2) pushing commit
3) rewrite commits,
4) rewrite stack,
5) use feature branches,
6) use long lived branches,
7) exchange draft changesets,
8) collaborate with other on draft branch.

Each time the user takes one of this steps, he should just have to add a 
small overlay to what he already know about Mercurial. For example 
moving from (1) to (3) just means learning about the '--amend' flag, the 
`hg commit` commands do not needs to be replaced by something else to 
deal with (1). Or when it starts exchanging changeset with other, it 
just needs to learn about `hg pull` and `hg pull` not replace the other 
command he already use locally.
In the same way, when moving from local only rewrite to distributed 
rewrite, we should just adds the minimum amount of complexity (eg: hg 
evolve) and be able to leverage all already known command from the local 
workflow. So if "reviving" and editing commits needs a different command 
set for the local and distributed case we would be on the wrong track.
Such smooth transition in the UI also allows member of the same team to 
collaborate at their level, since no simpler command used by simpler 
user will conflict with some other more advance usages.

What I'm trying to say here is that the delta of complexity between each 
step is probably as important as the punctual complexity of each steps.

(I'll spent my next chunk of time reading the Jun proposal (that might 
obsolete the current proposal), I'll have a deeper look at the current 
proposal after it.)

Cheers,

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list