Always apply (and hide) some patches

[Dr Rainer Woitok]

Danylo,

On Monday, 2017-06-05 09:04:04 +0300, you wrote:

> ...
> MQ hardly solves my problem. Here is an example of my current workflow:
> 
> 0. Repo has secret commit WORKSPACE, which contains my local changes to
> project infrastructure

I'm not quite sure whether your "secret commit WORKSPACE" really is part
of your workfow  or whether it's rather  part of your solution for push-
ing your development changesets upstream.

In a nutshell: using Mercurial Queues involves having two totally separ-
ate repositories,  your pristine clone  of the  upstream  repository and
your personal  ".hg/patches/"  repository  containing  your patches.  As
long  as you keep your patches  in the ".hg/patches/" repository you can
arbitrarily  apply them to  or unapply them from  your clone  of the up-
stream repository, you can reorder your patches and so on.

> 1. Make changes, test, commit.

Making a change mainly refers to a change in one of your patches in your
".hg/patches/" repository,  either a new patch  or some change to an al-
ready existing patch.  Committing this change refers to committing it in
the ".hg/patches/" repository only, your main repository is still prist-
ine.

While in your ".hg/patches/" repository  multiple commits can be associ-
ated with a particular patch,  applying this patch to the main repsitory
always results in a single new changeset on top of your main repository.

> 2. histedit and reorder secret commit WORKSPACE at top

Reordering of patches is done without "hg histedit" simply by either ed-
iting file "series" within your ".hg/patches/" repository while all your
patches are unapplied  or by using the "--move" option of the "hg qpush"
command (which does the same thing).  This change within the ".hg/patch-
es/" repository of course requires to be committed there.

Using Mercurial Queues you would most probably  move your finished patch
down to the  base of the  patch queue.   That's the place from where the
patches  are finally moved  to the main  repository  by issuing  the "hg
qfinish" command.

After having issued  this command  your main  repository  isn't pristine
anymore:  it contains exactly one outgoing changeset.   And "hg qfinish"
will normally also delete  your finished patch  from your ".hg/patches/"
repository, another change to your ".hg/patches/" repository which requ-
ires to be committed there.

> 3. change phase to draft for my new commit

By default  all changesets in both your repositories  already have phase
"draft" so this isn't necessary when using Mercurial Queues.

> 4. push

Now you have successfully pushed your most recent feature upstream.

> 5. update to my new commit

Your new commit, that is,  your just finished patch already IS on top of
your main repository, and your main repository is again in sync with up-
stream.

> 6. commit as subrepo change in another meta-repo

No problem.

> 7. update to WORKSPACE, so I can work on new features

This simply translates to  reapplying your  remaining patches  (if there
are any) to the main repository or to create a new patch.

Sincerely,
  Rainer