development heads up: push/pull improvements

[Manuel Jacob]

On 17/03/2021 16.05, Pierre-Yves David wrote:
> Hello everyone,
> 
> I have been working on improvements to push and pull. The core goal can 
> be summarized as:
> * make it simpler to push/pull to multiple destinations
> * make it simpler to control default behavior from various destinations.
> 
> The first bits of this already landed.
> 
> * Support for multiple destinations for pull (push is in review))
>  Â  https://www.mercurial-scm.org/repo/hg-committed/rev/685383486d0a
> * Support for default value for path suboption:
>  Â  https://www.mercurial-scm.org/repo/hg-committed/rev/e3f15c553522
> 
> My plan is to follow up with an handful of other improvements:
> 
> 1) Make it possible for a path (in [paths] section), to reference 
> another one using `path://PATHNAME`, inheriting its configuration. The 
> inherited configuration can then be overwritten in the new path
> 
> 2) Make is possible for a path to reference a list of other paths. eg:
> 
>  Â  [paths]
>  Â  main = https://mercurial-scm.org/repo/hg
>  Â  committed = https://mercurial-scm.org/repo/hg-committed
>  Â  all = path://main, path://committed
> 
> 3) add sub-options to control usage of existing flags. For example the 
> following config would make `--new-branch` on by default for the `devel` 
> path.
> 
>  Â  [paths]
>    devel = ssh://foo…
>  Â  devel:new-branch=yes
> 
> The possible values would be:
> 
> * never: the flag is never set, using --new-branch would abort the push
> * no: the flag default to False, passing --new-branch enables it
> * default: the default value for the flag is used
> * yes: the flag default to True, passing --no-new-branch disables it
> * always: the flag is always set, --no-new-branch would abort the push

I really like this feature. I don’t really see the point in "always", 
but we can have it for symmetry with "never".

Speaking of defaults, it would make sense to me to allow pushing new 
branches in draft phase by default, since the original point of 
disallowing it was probably to prevent people from making the branch 
name permanent, which isn’t a problem with draft changesets.

One nice thing would be to be able to specify the flags for all paths 
matching some pattern. This may seem complicated, but doesn’t add much 
more conceptual overhead in addition to the `*` special path.

For the name of the config, see the discussion below (we should use the 
same names for the config and CLI flags).

> 4) adding more flag
> 
> They are a couple of check that does not have there own flag yet and are 
> only covered by `--force`. For example to push new heads. I know that 
> Manuel Jacob had idea about how to express these flag, so I CCed him on 
> this email.

The basic idea is simply to have a flag for each check to turn it off or on.

One issue is the naming, which probably requires some bideshedding. The 
existing "--new-branch" never really made sense to me (it sounds as if 
it always added a new branch instead of disabling some check).

Before shipping a bunch of new flags, it would be good to get it right. 
Another reason for having a better naming scheme would be that a common 
prefix (not every flag will start with "new") creates a bit of grouping 
and aids auto-completion.

For disabling checks, prefixing it with "--allow-" makes sense to me. 
The first flags to add would be:
--allow-new-branch: allow adding new branch on destination
--allow-new-head: allow increasing the number of heads on a branch on 
destination

For the checks about not pushing obsolete, orphan, divergent and similar 
changesets, I proposed some changes (I think the existing checks miss 
problematic cases and reject legitimate ones). Pierre-Yves was concerned 
about breaking expectations of users relying on the old behavior, so 
this was never released. By making it possible to turn off and on 
various variants of the checks, new behaviors can be designed and 
developed in an incremental way. This is especially useful considering 
that more advanced detection algorithms depend on accurate obsmarker 
discovery, which is currently not in core.

> This work is not my primary focus, but hope to make enough progress to 
> have most of it completed by the 5.8 freeze, in one month.

I won’t be able to start the “split --force” effort before the 5.8 
freeze, as I‘m in the process of renovating my flat, but I’ll try to 
give feedback about your efforts. Thanks for CCing me! In the next 
release cycle, I will be able to spend time implementing stuff.

> Cheers,
>