Fwd: Hidden Commits in 4.3

[Durham Goode]

On 4/5/17 9:58 AM, Martin von Zweigbergk wrote:
> *sigh* I was confused by the gmail/inbox default reply yet again. The
> below was meant not just for Greg.
>
> Doesn't really add much value at this point :-P
>
>
> ---------- Forwarded message ----------
> From: Martin von Zweigbergk <martinvonz at google.com>
> Date: Tue, Apr 4, 2017 at 9:20 PM
> Subject: Re: Hidden Commits in 4.3
> To: Gregory Szorc <gregory.szorc at gmail.com>
>
>
> On Tue, Apr 4, 2017 at 8:58 PM, Gregory Szorc <gregory.szorc at gmail.com> wrote:
>> On Tue, Apr 4, 2017 at 6:11 PM, Durham Goode <durham at fb.com> wrote:
>>>
>>> There's been a lot of discussion about how to hide and unhide commits
>>> lately [0][1], and I feel the complexity of our current approach is hurting
>>> our ability to reason about it, making it impossible to make progress.
>>>
>>> I would like to formally propose a new pattern for dealing with hidden
>>> commits, along with the concrete steps to getting it enabled in core by
>>> default by the August release.
>>>
>>> The proposal is quite concise, so check out this 1-page Google doc for the
>>> details and to comment:
>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__goo.gl_7DJ9AI&d=DwIBaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=nuarHzhP1wi1T9iURRCj1A&m=9ujoyPVTKANNXyeB-TWto89n1J_Wgrj9nn1gn38N_xE&s=Dol8nY676yUOBn4FDWvmMdPgoxALSIH2aLElSDOA760&e=
>>>
>>> If people find this approach promising, I can commit to trying to get this
>>> upstream by the August release. So if you have questions or concerns, please
>>> let me know so I can address them.
>>>
>>>
>>> [0] see: "obsolete: track node versions"
>>> [1] see: "repo: add an ability to hide nodes in an appropriate way"
>>
>>
>> I lost track of all the developments in the various ongoing threads about
>> hidden changesets and obsolescence versioning. So thank you for taking the
>> time to write a concise summary.
>>
>> I emphatically support your proposal of introducing a non-obsolescence
>> mechanism for hiding changesets. It solves a very real and very painful
>> deficiency in the storage model (strips required to rewrite history) without
>> forcing complicated workflows and concepts onto users (evolve). As I said at
>> the sprint, the horrible performance associated with history rewriting
>> without obsolescence enabled is one of Mozilla's biggest pain points for
>> large repos. I can't in good faith recommend evolve to all users because it
>> is too complicated and can lead to unexpected behavior.
>>
>> I think this proposal for hidden changesets solves the performance problem
>> while not preventing obsolescence/evolve from making progress in its problem
>> space. It also doesn't seem to be as cognitively difficult on users.
>
> I agree.
>
>>
>> There are some areas that need flushed out of course. Obviously storage. But
>> I think the more important problems are the user-facing ones. e.g. what
>> happens if a user updates to a hidden changeset and makes a commit? Do we
>> allow that? I think there needs to be some kind of UX to discourage
>> accidental usage of hidden changesets or at least warnings when things
>> become unhidden because that may be unexpected.
>
> Good question. Durham didn't say it explicitly, but I think you're
> right that checking out a hidden commit probably unhides it (and its
> ancestors).

The doc mentions 'hg checkout hash' unhides it.  Along with bookmark 
placement and the explicit 'hg unhide' command.

>
>> That's why things in the doc
>> like `hg checkout HASH` automatically unhiding a changeset make me a little
>> nervous.
>
> I agree that some warning/note is probably appropriate to let the user
> know that we unhid it.
>
>> Same with `hg pull` automatic unhiding. It seems like it is almost
>> too easy to create divergence without any helpful mechanism (obsolescence)
>> to recover from it. What I'm still trying to contemplate are the workflows
>> where this would most likely occur. If it is only rare scenarios or things
>> we don't want users doing, I think it can be tolerable.
>
> We need concrete uses cases to discuss this. The obvious ones seem
> safe and correct to me (ex: I pull from Greg and hide a branch I don't
> care about, then I pull again and it reappears -- seems right to me).

This is mainly there for backwards compatibility reasons. If people have 
automation that is stripping commits and then potentially reapplying the 
commits (via unbundle or pull), then not having those commits be visible 
after the pull/unbundle in this new world would be a breaking change.

This let's us enable the feature by default with less risk to existing 
deployments.

>>
>> I'm also curious if you intend to add a new repo requirement for this. If
>> not, what's the story for a legacy client interacting with repos with the
>> new hidden mechanism? IMO that experience is bad enough (legacy client would
>> see a bunch of visible changesets that should be hidden) that I think it
>> warrants locking out old clients.
>
> Even though the hiddenness is not exchanged, it doesn't have to mean
> that the hiddenness is not involved in exchange, does it? I would
> think the repo would look like it didn't have the hidden nodes. I'm
> sure it's trickier than that, but I'm not sure how.

Exchange would work exactly the same as today.  If the commit is 
stripped today, it is not exchanged. If the commit is hidden in the 
world of tomorrow, it is not exchanged.