Hidden Commits in 4.3

Ryan McElroy rm at fb.com
Mon Apr 10 17:16:12 EDT 2017


I don't see as big of a conflict between evolve and locally hidden as 
others on this thread. I have a couple of specific responses below. But 
first, I wanted provide some specific examples of how this propsoal 
could/would work (I think a few people [martinvonz?] wanted this to 
ground the discussion). I think the examples will make it clear how this 
hiding proposal would make things a lot better for Mercurial in the 
short term.

First, a confession: My previous replies to this thread were tainted by 
the fact that I didn't know that obsolescence-based hiding was already 
in core. I thought it was added-on by evolve. Thanks to Pierre-Yves, 
Jun, and Durham for pointed out to me privately that I was missing that 
key fact.

Now, some examples of how this simple version of hidden-ness could work 
in practice. The key point is that this new hiddenness can simply 
replace all stripping that happens today, and so we can make it behave 
in the same way that things work today, but without the slow and fragile 
bundling and stripping process.

---

EXAMPLE 1: `hg commit --amend`

* Instead of bundling and stripping the old changeset, we simply create 
a new changeset and hide the old changeset.
* If we have exchanged the old changeset, we would get the old changeset 
back when pulling from the peer we exchanged with (this is exactly what 
happens today with strip-based amend).
* If we unhide the old changeset, we will see the old changeset again 
(this is exactly what happens if we unbundle the old changeset today).
* If obsolescence markers are enabled, we also create one, so that more 
advanced exchange workflows can work well.
* Note that we no longer need to use obsmarkers to hide the "temporary 
amend changeset" as we currently do. We can use the new hiding mechanism 
for this, which is more correct.

In summary, all behaviors are exactly the same as today, but they are 
faster, safer, and easier to recover from.


EXAMPLE 2: `hg shelve`

* Instead of creating a partial changeset, bundling, and aborting, we 
can create a real changeset and then hide it. This is faster and far 
safer than the janky aborted transaction that shelve uses now.
* If the same changeset is pulled from another server, we will show the 
changeset (this is exactly what happens today with abort-based shelve).
* If the same changeset is unbundled, we will show it again (this is 
exactly what happens today with abort-based shelve)
* No need to create obsmarkers for this case; there is no history 
rewriting going on that needs to be globally understood.

In summary, all behaviors are exactly the same as today, but they are 
faster, safer, and it is easier to recover from errors.


EXAMPLE 3: `hg rebase`

* Instead of bundling and stripping the old changesets, we simply mark 
them as hidden.
* If any of the old changesets had ever been exchanged or bundled, 
pulling from a peer with those changesets or unbundling would unhide the 
old changesets. This is the same behavior as with strip-based rebase today.
* If we unhide the old changesets, it's the same as if we unbundle the 
changesets from strip-based rebase today.
* If obsolescence markers are enabled, we also create those for the old 
changesets, so that more advanced exchange workflows can work well.

In summary, all behaviors are exactly the same as today, but they are 
faster and safer, and it is easier to recover from mistakes.

There's an obvious theme here. I'm not trying to overly simplify 
anything here, so let me know if you see issues, but basically I only 
see positives.

Again, the key here is that this provides a much better speed and safety 
win compared the the current strip-based approach. The downsides are 
exactly the same as with current strip-based workflows: old changesets 
can show back up and be confusing. Future extensions like evolve can 
solve those problems, but this proposal is generally only better along 
any axis you compare it to the current way hg works.

---

I strongly feel that we should move in this direction -- it would be 
huge win for everyone who uses mercurial over the workflows that they 
have today. I hope these examples can help everyone see how this new 
hiddenness concept can make all these workflows a lot better inside core 
within the next 3 months. I also hope that the interactions with 
obsolescence markers I've outlined show why this proposal doesn't 
interact badly with evolve's global state paradigm either. It also 
nicely solves concerns like those that come up with Kostia's obsshelve 
series as well -- we will have a way to hide that is separate from 
obsolescence, so everyone should be a little more happy.


The final topic to discuss is how does this new hidden concept interact 
with evolve's hiddenness concepts? I've convered this below in my 
response to Durham and Pierre-Yves's email thread. The short version is 
that I believe both concepts can co-exist with no issues. Hiddenness 
doesn't need to affect evolve's global state obsstore graph -- all the 
same decisions evolve makes today can be make regardless of what is 
visible or hidden. There can be an evolve-based way of choosing hidden 
that may be different than core's, but no command behaviors need to 
change as far as I can tell.

So, I vote for moving forward with a hidden feature in core that will 
unlock all of these nice behaviors for users in the short term and will 
not hinder progress on more advanced workflows in the long-term.



On 4/7/17 12:29 PM, Pierre-Yves David wrote:
> I agree that having a local-only hiding mechanism would be a win.
>
> However obsolescence and the hiding computed from it must stay fully 
> independent from it. Changeset-evolution relies on building a global 
> state[1] mixing it with local-only elements breaks this property.

I don't think local hiding needs to interact with evolve in any breaking 
way. See below for why.

>> I believe these benefits outweigh the downside to evolve's current goal,
>> […]
>> 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. 
> This is not a "small downside" to evolution goal. This is a full stop 
> to our ability to ship changeset-evolution.

I don't think Durham's hidden proposal and evolve are mutually 
exclusive. The obsolescence global state can be used with or without any 
specific implementation of hiding -- hiding is an important feature to 
prevent the end-user from becoming confused, and evolve should have an 
implementation that makes sense. Regardless, hiddenness doesn't need to 
affect the destination of an 'evolve' command -- that can and should 
work with or without any given changeset being visible or hidden.

> The current proposal is destroying at least one pillard currently 
> holding the changeset-evolution plan (global state), without 
> replacement. As of today, this kills our ability to complete and ship 
> changeset-evolution to all Mercurial user in the next year or two.
>
> This is not a small subjective adjustment, this is a full 
> discontinuation of concept critical to the future of Mercurial.

I think there is not so much conflict here. As the examples above show, 
the new hidden UI in core preserved current behavior, but in a safer and 
faster manner. I also think it does not block or hurt evolve's global 
state at all. These concepts are independent from what I can see. I 
think getting hiddenness features into core now, for all of the benefits 
that will bring, is pretty important.

~Ryan


More information about the Mercurial-devel mailing list