Hidden Commits in 4.3

[Sean Farley]

Durham Goode <durham at fb.com> writes:

> I respond below, but I believe Jun has sent you a innovative proposal 
> that may solve both of our needs and render this discussion irrelevant. 
> So take a look at his proposal at your earliest convenience, since it 
> may let us put this behind us.
>
> On 4/18/17 11:03 AM, Pierre-Yves David wrote:
>> On 04/14/2017 01:04 AM, Durham Goode wrote:
>>> On 4/13/17 2:37 PM, Pierre-Yves David wrote:
>>>> On 04/12/2017 04:23 PM, Ryan McElroy wrote:
>>>>> […]
>>>> *Practical example* (/simplified/):
>>>>
>>>>    Situation:
>>>>
>>>>      * Facebook has a useful: hg undo command.
>>>>      * Facebook cares about hg undo, preserving the hash,
>>>>      * this hash preservation conflict with current constraint of
>>>>        changeset-evolution.
>>>>
>>>>    Way forward:
>>>>
>>>>      * Facebook can upstream hg undo with hash preservation,
>>>>      * We introduces a variant that changes the hash and makes it
>>>>        available to all users with BC,
>>>>      * Facebook can set the config for hash preservation internally.
>>>>
>>>>    Result: the code is upstream, user has new feature and we can
>>>>    discuss hash preservation later.
>>>
>>> I think this example is missing the step where we discuss what we should
>>> ship to users. My goal is not to enable Facebook to have a feature (we
>>> already have these features), my goal is to create a good user
>>> experience for Mercurial users. If we do the config knob route, we must
>>> at some point have the discussion about what experience we want to give
>>> to users, before we actually ship it to them.
>>>
>>> So in your proposal, when will it become appropriate to have that
>>> discussion? And what can we do between now and then to make that
>>> discussion more productive? I think we're blocked on getting bits into
>>> the hands of users by default until then.
>>
>> (note: I've purposely delay more "discussion" oriented part in my other
>> email (that you also replied to) I'll reply to it too shortly after this
>> one.)
>>
>>
>> In my example above, once "hg undo" is upstreamed, we are able to build
>> a variant without hash preservation[1] and ship that the user by default
>> without delay.
>
> I'm sure you don't mean it this way, but this sounds a lot like "let's 
> ship my thing and we'll figure your thing out later". The moment evolve 
> ships, it becomes a lot harder to make the types of changes I'm talking 
> about (both from a user experience point of view and community 
> momentum), so I'd rather have the discussion now while it's still 
> possible to make important changes.  If we flipped the sentence around 
> (ship mine, figure yours out later) I'm sure you wouldn't be happy with 
> that outcome either.

For what it's worth, I did not read it that way. Also, I've tried to
avoid this discussion (across all the various threads) because it has
been draining.

>> On a general principle, decoupling implementation discussion from UI
>> polishing is usually a win.
>
> If we decoupled UI from implementation here, we'd just go ahead and ship 
> "hg unhide" with hash preservation, since that's objectively the more 
> intuitive UI for unhide. But since the implementation of the obsolete 
> graph doesn't allow that UI, implementation therefore affects our 
> discussion.

At first reading of this, I find this kind of hostile from Facebook. I'm
sure you didn't mean it that way but eh.

I found it hard to reply to this thread because of all the different
derailings. For every non-Facebook dev here, there are so many more
Facebook devs to reply to. That is exhausting. *I* am exhausted.

> I'd love to discuss the pro's and con's of these two ideas purely from a 
> UX standpoint, but I haven't seen any concrete examples of situations 
> where evolve is affected by this for us to have a tangible discussion 
> around it. If we had a concrete example, we could more productively 
> evaluate the pro's and con's of these ideas.

There's so much convolution in this thread. For instance, I think (fast)
local hiding would be cool. A version of that is possible today and I've
even had my hand at it:

https://bitbucket.org/seanfarley/hgremotenames/commits/69cda2b8353ab1b108ca120d08eb253941f9ae70?at=hideable

That's remarkably simple and having a bitmap (or whatever) api would be
good. I'm surprised there has been so much misinformation and changing
of the goal posts. For instance,

* obs marker are global state

  I didn't think this was even a point to be contested. Distributed
  systems is difficult and evolve is solving a hard problem of shared
  rebase, histedit, etc.

* hash preservation

  Sure, that's neat. But that's not a blocker. Like, not even a little
  bit. If I hear Jun say that obs-based hiding is broken by design one
  more time, I might roll my eyes so hard that they'll fall out the back
  of my skull.

> Given that evolve has been around for years and people still aren't able 
> to reason about concrete examples in these discussions, I don't think 
> the strategy of 'give it more time' is going to help move this 
> discussion forward.

The last time I discussed this with you, I was under the impression that
your plan was:

- turn on obs-based rebase (perhaps histedit) but disallow unstable
  changesets

- augment the UI with a list of operations for diverged changesets, e.g.

  $ hg rebase foo
  you have two choices:
  1) abcd0123
  2) deadbeef

None of the above, in my mind, requires the unhiding / cycle business.
To me, getting the above points in core first (just making the happy
path working, basically) would be a win. If that's not the goal, then
I'm not really enthused about your proposals.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170420/247c0adb/attachment.sig>