Always apply (and hide) some patches

[Arne Babenhauserheide]

Danylo Hlynskyi <abcz2.uprola at gmail.com> writes:

> 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.

Why can’t you use secret commits? Do you mean that this cannot be
implemented cleanly or that it is not the current behavior?

>> 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
…
> $ hg to-local [BRANCH]
> Marks 'tip' commit of a named BRANCH (or current branch, if nothing
> specified) as local to this repo.

Having this as a single command sounds good. The need to overwrite
commands might make this harder than other methods. 

What I don’t understand is why you need a separate class of
commits. Your description sounds like you just need secret phase (which
is never exchanged with others) plus automatic grafting of new commits
into the non-secret commits.

> 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.

If you have only a single commit, you can simply graft the local commit
on top of the new one. With grafting you get rid of the need to have
real merges. 

Good luck and happy hacking!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20170606/a38848d4/attachment.asc>