Hidden Commits in 4.3

[Pierre-Yves David]

On 04/06/2017 02:46 AM, Jun Wu wrote:
> obsstore-based hidden is broken by design, since it cannot unhide commits:
>
>   $ hg export . > patch.txt
>   $ hg prune . # could also be done by pulling obsmarkers from a remote
>                # peer, or it could be amend / metaedit etc.
>   $ hg import --exact --bypass patch.txt # cannot really import the patch

The case you describe above work as intended.

By using "hg prune ." you globally marks the changeset as an undesirable 
dead-end (obsolete-pruned)[1]. re-obtaining the same changesets in this 
repository or in another will not affect this global state. We are just 
adding global informations together:

   The changeset exists + a prune marker exists == this changeset is 
obsolete.

This global state is a critical part of changeset evolution, and the 
visibility rules computed from obsolescence are fully parts of this 
state[2].

The uses can change their mind and bring the changes back to life. We 
currently have a basic command `hg touch` doing so (more useful friendly 
alternative are in project),

To "bring" this changeset back to life, new information needs to be 
added. In addition, currently the changesets is "brought back" with a 
different hash.  A new changeset node "NEW" and an obsolescence markers 
marking "NEW as a replacement for OLD" are created.

This hash changes is necessary as the current implementation of 
evolution relies on "monotonic rewrite"[3] that ensure different actions 
will always creates a new nodes. These monotonic rewrites comes with 
many useful property to simplify the problems evolution as to solves[4]. 
  The hash change is not the best thing from user experience 
perspective, but it practice the impact is very minor[5].

They -might- be ways to introduce new mechanism that would lift the need 
for monotonic rewrites while still solving the same problems. So far, 
such mechanism are unknown and concrete plan does not exists. The 
current roadmap focus on being able to ship evolve to all with monotonic 
rewrites.

[1] 
https://www.mercurial-scm.org/wiki/CEDConcept#Obsolescence_markers_semantic
[2] https://www.mercurial-scm.org/wiki/CEDConcept#Global_State
[3] https://www.mercurial-scm.org/wiki/CEDConcept#Monotonic_rewrite
[4] https://www.mercurial-scm.org/wiki/CEDConcept#Problem_this_Easily_Solve
[5] https://www.mercurial-scm.org/wiki/CEDConcept#User_Impact

> The new ui requires the ability to unhide commits. So hidden-ness should not
> be affected by obsstore.  That means extra work is needed to make sure
> commands like amend also write to the new hidden store if they write
> obsolete markers to hide commits today.
>
> I think most people agree on this. I just want to make it clear as
> Pierre-Yves does not mention this aspect in his long text.

So far, I'm not seen a rational for hash-preservation been a 
-requirement- nor a group of people agreeing it is a -requirement-.

Sure it would be nice, but "nice" is different from -required-.

This is probably a core point we need to iron out in this discussion.

On 04/05/2017 11:22 PM, Jun Wu wrote:
> […]
> There are some questions that I'm waiting for your answers:
>
>   - Define "user intention" about adding a obsmarker formally [1]

I've started formally writing some of the evolution concept.
Does this section fits your need:

* 
https://www.mercurial-scm.org/wiki/CEDConcept#obs-marker:_General_Principle

>   - Why "an unified hidden store" does not work [2]

Changeset evolution is based on a global state created by the 
obsolescence markers. The hiding from evolution is a computed property 
of this global state. It -cannot- be delegated to an independent, local- 
only, user manipulable hiding mechanism. Hiding from obsolescence 
markers is a "static" property that -must- remains independent from the 
local hiding mechanism (See previous [2] for details).

Local-hiding has its own merit and would help various usecase. The two 
mechanism can perfectly exists side by side.

On 04/05/2017 11:50 PM, Jun Wu wrote:
> I think it's unnecessary to have "internal changeset" concept separated from
> the general-purposed hidden.

They are some case where having explicit internal changeset are useful:

Case 1: looking at hidden changeset,

   When the user want to look or query the set of hidden changeset (eg: 
user remember he hided something he now needs). Commands will be run to 
see `hg log --hidden` or even select `hg log --hidden --rev 'hidden() 
and file('foo/bar') and date(-7)'`.
   Without an internal changesets, this command will display and select 
internal changesets that are irrelevant/scary to the user. Having 
explicit "internal" changesets allow to filter them out of such search 
from the user.

Case 2: History of hiding

   I can expect user to request a command displaying the history of what 
they hide/archived[6]. They could use it to undo things. Without 
distinction between archived and real changesets, this history will list 
hiding and changesets from internal operation, surprising/confusing the 
user and polluting the output.
   If we have explicit "internal" changeset we can clean up these 
output. If make them life in their own way (phases), we do not even have 
do deal with them when building such UI.

How do you plan to handle theses cases ?

> But if the community do decide to implement the
> internal changeset concept, I think that could be doable, but it should be
> done in the new non-phase store, instead of adding a new phase.
>
> Therefore, I'm -1 on adding a new phase in all cases, since there are better
> choices.

Can you elaborate on why think a non-phase approach is better to 
implement an "internal" concept.


Cheers,

-- 
Pierre-Yves David

[6] I like archived as a word for this.