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