( )⚙ D179 fbamend: add unhide command for easy unhiding of commits

This is an archive of the discontinued Mercurial Phabricator instance.

fbamend: add unhide command for easy unhiding of commits
ClosedPublic

Authored by mitrandir on Jul 24 2017, 8:11 AM.
Tags
None
Subscribers

Details

Summary

This command helps the user to bring back the commits to life with an explicit
command - wihtout the need to change working copy parent or create bookmarks.

Test Plan

see test

Diff Detail

Repository
rFBHGX Facebook Mercurial Extensions
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

mitrandir created this revision.Jul 24 2017, 8:11 AM
Herald added a reviewer: Restricted Project. · View Herald TranscriptJul 24 2017, 8:11 AM
quark requested changes to this revision.Jul 24 2017, 12:19 PM

There are 2 concepts: visible, and obsolete. Is it intentionally to unobsolete commits? If not, I'd rather just change visibility while still making the commit obsoleted (via hiddenoverride, not inhibit), since that will not cause divergence (which could confuse auto rebase and make future workflows harder).

This revision now requires changes to proceed.Jul 24 2017, 12:19 PM
quark accepted this revision.Jul 25 2017, 1:11 PM

Per discussion internally, the local unhide/hide concepts could be too complicated and a common user won't be able to distinguish between unhide and revive/touch. So let's make unhide/touch the same thing then. We can revisit this later.

This revision is now accepted and ready to land.Jul 25 2017, 1:11 PM

I was thinking something along the lines of hg hide --global REV and hg unhide --global REV for the "make this visible/invisible everywhere" idea.

quark added a comment.Jul 25 2017, 2:34 PM
In D179#2789, @ryanmce wrote:

I was thinking something along the lines of hg hide --global REV and hg unhide --global REV for the "make this visible/invisible everywhere" idea.

I'm more concerned about the complexity here, both concept-wise and implementation-wise. I'm leaning towards global-by-default now.

I was thinking this way: what's the downside if we go the always-global approach? Unwanted divergence and unwanted strip of others' commits when exchanged. They seem easier to solve than the complexity of local hidden.

mitrandir updated this revision to Diff 412.Jul 26 2017, 12:01 PM

refactor to use repo.set and context managers

This revision was automatically updated to reflect the committed changes.