Hidden Commits in 4.3

[Denis Laxalde]

Augie Fackler a écrit :
> On Fri, Apr 07, 2017 at 12:20:44PM +0200, Pierre-Yves David wrote:
>> 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.
>
> I know it's the original intent, but I'm not sure that the original intent is actually a desirable set of outcomes. I've actually tripped over this usability wart a decent number of times, usually some variation on this theme:
>
> hg pull marmoute-wip -r some-feature
> hg co some-feature
> hg rebase -d @
> <poke a bit>
> hg strip 'ancestors(some-feature) and not ancestors(@)'
> <time passes>
> hg pull marmoute-wip -r some-feature # which has not moved since the last time I pulled
> <it appears nothing happens>
>
> This briefly confuses *me* when I trip over it, and I've helped work out some of the design of the feature, which strongly suggests to me that the "is listed as a precursor in an obsmarker means its always hidden" behavior is suboptimal in the real world. As a rough cut of how we might reconcile usability and theory, I wonder if the correct path is to have obsmarkers immediately hide things (if possible) only when they're first introduced (likely through pull), but if the user takes an action that unhides, we just do that and then there's some advisory mechanism by which they can be told that things have been obsoleted.

I'm also confused by this kind of things. Another example is:

* pull a changeset to publish (hg phase -p)
* rebase it on top of the public head
* change your mind (because, for instance, tests fail)
* from this point, there's no simple way to get the original changeset
   and, more importantly, remove the obsmarker that'd get exchanged upon
   next push.

If I understood correctly, this issue would be solved by improving "hg
strip" to remove the obsmarker.


>> 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.
>
> I'm starting (based on the above rough edges that I've tripped on more than once) to be of the opinion that supporting hash preservation is effectively non-optional because of workflows people already have in their brains. It also makes a bunch of cases in tools like histedit and commit --amend easier to write (and harder for future extension authors to screw up!) to get that working in a sensible way.
>

I also think that hash preservation would be nice when it comes local
operations. This is important when exchanging with others to prevent
information that should remain local to propagate. Basically, in my
example above or yours, we don't want to exchange our local round-trip
operations.
But if one happens to have exchanged (pushed at least, not sure about
pull) the information, I think it does not sound unreasonable that
unhiding a changeset changes its hash (unless there is another possible
mechanism, like the "layer on top of obsmarkers" in the plan document).

Apart from this case of local-only operations, it's not very clear to me
why hash preservation would so important.