Always apply (and hide) some patches

[Danylo Hlynskyi]

Hi Arne

> Did you already try whether the evolve extension provides this for you?

I'm already evolve user. Except that it changes
restore-after-wrong-history-edit workflow,
I see no difference with or without it. Evolution doesn't
complicate/simplify my workflow.

I can't base my work on top of hidden commit, because that would still
require rebasing.
And I can't base hidden commits on top of my changes, because they aren't
moving targets
and won't be autorebased after I commit.

> That way you’d just need to run a single command to make your last commit
non-secret.

Yes, that kind of workflow can be automated. What you've described is
basically auto-reordering
using histedit

Now, as we discuss it, I understand that this can be done with extension.
Here's an intended UI:

-----
$ hg to-local [BRANCH]
Marks 'tip' commit of a named BRANCH (or current branch, if nothing
specified) as local to this repo.
Most hg commands will ignore this commit, but the actual working directory
will behave
like this commit is applied.

Internally, it is always rebased on top of latest updated commit in
selected named branch.

Local commits are not mergeable. If your hg <command> hit the merge
conflict with local, you have to
make local commit normal using `hg from-local` and then convert back to
local after merge is done.

hg log will show a "@local" tag when local commit is applied. You have to
pass flag --local to see actual
local commit.

$ hg from-local [BRANCH]
Makes local commit in selected branch as normal commit in 'secret' phase.
-----

The requirement "one local commit per named branch" is to simplify
implementation and solves
the need to track state.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20170606/e5060b43/attachment-0002.html>