Accessing hidden commits by hash (directaccess extension)

[Danek Duvall]

Durham Goode wrote:

> 
> 
> On 8/25/17 11:55 AM, Danek Duvall wrote:
> > This is great.  I've been hitting my head against this ever since I started
> > using evolve, and I'll be thrilled to have this functionality.
> > 
> > A couple of questions:
> > 
> >   - If a revision range is given that ends (or begins, I suppose) with a
> >     hidden changeset, will any intervening hidden changesets also be
> >     temporarily unhidden?
> 
> The unhiding mechanic unhides the commit and all ancestors.  So those
> ancestors will be returned as well.  Descendants are not returned, so
> HIDDEN:: will only return HIDDEN.

Okay, that makes sense.

> >   - The recoverable-write commands often pop you into an editor before any
> >     warning can be seen and understood.  Should the warning be available in
> >     the editor template?
> 
> I'm open to the idea. I don't know how many people actually read the editor
> template after seeing it a few times, so I'm not sure how useful it would be
> in practice though.

Yeah, I don't know what the right answer is here, either.  Maybe the syntax
highlighting in standard editors could be updated to make the message stand
out a bit.  Otherwise, the only things I can think of are either to have a
pause before the editor fires up or to just print the message and hope for
the best.

There's no protocol for integrating with IDEs in this situation, is there?
Something that would allow the IDE to pop a warning box?

I dunno; maybe it's overengineering, at least for now.  The whole point of
recoverable operations is that you can undo your mistake once you've
realized you made one.  Hm.  Maybe a message after the editor exits is
another option.

> >   - The unrecoverable-write commands could probably stand to explain why
> >     they're preventing the operation from happening, but perhaps more
> >     importantly, if you use --hidden with them, will they actually
> >     push/serve/whatever?  I guess I can see wanting a complete clone of a
> >     repo, including hidden changesets, so pushing them around would make
> >     sense in that context, but I thought we weren't going there.
> 
> The messaging could be tweaked, sure.  If the user wants to bypass the
> block, then --hidden will let them do the push/etc. We probably won't
> advertise that though.

Okay.

> In the longer term, we have UI's within Facebook that we hope to upstream
> that allow recovering a commit (with the same hash it had before), so users
> could first recover the commit (which makes it clear they are explicitly
> bringing the commit back) and then push it.

That's clearly the better UX for normal users.

> > Along similar lines, I've also wanted the ability to push and pull secret
> > changesets between (non-publishing) repositories, but only when specificied
> > by name like this.  Seems like there could be some shared mechanism there,
> > if it's not just me.
> 
> We don't really use secret commits here. Instead, we've overriden the push
> behavior to require the user to specify what they want to push and where
> they want to push to (hg push -r mybookmark --to theirbookmark). So we
> haven't really needed secret as a mechanism for controlling exchange.

Sure, though of course not everyone works at Facebook, and those that do,
might work in other contexts, too.  It's certainly a workflow I've found
useful in the past.  I'm certainly not asking for implementation here, just
a confirmation that there's enough alignment here that implementing that at
some point would be easier because of your work.

Thanks,
Danek