Durham Goode <dur...@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.
signature.asc
Description: PGP signature
_______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
