Hidden Commits in 4.3

Ryan McElroy rm at fb.com
Thu Apr 6 08:47:18 EDT 2017


(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


More information about the Mercurial-devel mailing list