(text re-arranged for clarity)
On 4/6/17 1:46 AM, Jun Wu wrote:
Excerpts from Pierre-Yves David's message of 2017-04-06 01:01:19 +0200:
(important bit about how we -already- have a generic hiding API is at
the end of the email).
Thanks. I used that and had a working general-purposed, phase-based hidden
demo at the sprint [1]. So I think we are pretty familiar with the API
already.
[1]: https://www.mercurial-scm.org/wiki/4.2sprint#Enhanced_repoview
To be fair to Pierre-Yves, I had forgotten about it (though once he
mentioned it I remember that he had mentioned it to me before some years
ago).
However, if it's so easy to add new forms of hidden commits, why do we
care how evolve happens to implement hiddenness? Why not just add a
bitmap based hiddenness in core (so it's fast and scalable), let evolve
be a user of that system, and let other tools that want to do
hiding/unhiding use that system in a different way?
I guess what I fundamentally don't understand is why evolve (an
extension not yet in core) is intertwined with the discussion of a
hidden concept that it could use. Let evolve do things in its more
advanced way. Let core tools do things in a
better-than-today-but-not-as-advanced-way (particular since all of the
history rewriting tools are *already* extensions!)
On 4/6/17 1: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 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.
I think this is too harsh and not a fair assessment of what evolve does.
It is possible to unhide commits -- by putting a bookmark there, by
checking it out, by adding a local tag, by creating an extension like
inhibit, etc.
The import case above could have a better UI build around it that makes
it clear what happened: "imported patch already has a newer version
available", for example. That's not unreasonable.
However, I agree that it's not the easiest user experience to master --
when I import a patch, or unbundle, or whatever, I want to see the patch
show up in my log! That's what I expect.
Jun, I think I agree with you that "evolve doesn't behave exactly how we
want". But it's unfair to call it "broken by design". It's designed to
do something different (and more ambitious) than where we are aiming
right now. That's fine -- as should be clear from the extensions we
(Facebook) have made available [1], we don't expose the full evolve UI
internally anyway.
That's why I want to focus on a scalable hidden storage solution that
everyone can use (including evolve), and then we can improve the current
extensions (in and out of core) to use this new hidden storage. Evolve
can continue to do it's thing that will enable safe exchange of
rewritten draft commits. In my opinions, there's no need to try to
derail evolve's current roadmap as part of building that. I think evolve
can remain an interesting experience on top of whatever we're building
with this proposal. I don't see direct conflict.
[1] for example, 'hg rebase --restack' inside of the 'fbamend' extension
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
