remotenames: add functionality to override -B flag of push
AcceptedPublic

Authored by pulkit on Mar 15 2018, 9:49 AM.

Details

Reviewers
indygreg
Group Reviewers
hg-reviewers
Summary

This patch adds a new config option which can be used to override the -B flag
of push command. If config is set to true, changesets will be pushed to that
bookmark on the server. This is equivalent to --to flag of remotenames and
infinitepush.

After this patch if config is set to true, the behavior will be:

  • Normal push without -B flag: no behavior change
  • specifying one bookmark using -B flag: changesets will be pushed to that bookmark on the server, as explained above. Bookmark pushed will be on the head most revision of the changesets pushed.
  • specifying multiple bookmarks using -B flag: no behavior change, the same behavior as it's today without this config option
  • specifying multiple topologcial heads to push: no behvaior change

There needs some extra logic to update the remotenames state locally after the
push since we know that the bookmark will now be at a known updated location.

Diff Detail

Repository
rHG Mercurial
Lint
Lint Skipped
Unit
Unit Tests Skipped
pulkit created this revision.Mar 15 2018, 9:49 AM

I am not sure the functionality and config names should go to core or not, so I have introduced them in this extension. Also suggestions for better config names are welcome.

pulkit updated this revision to Diff 7103.Mar 19 2018, 4:36 AM
pulkit updated this revision to Diff 7249.Mar 22 2018, 3:35 AM
indygreg requested changes to this revision.Mar 23 2018, 2:56 PM
indygreg added a subscriber: indygreg.

I'm happy with this feature.

But the code needs work around multiple revisions/heads before it can be queued.

hgext/remotenames.py
99

What happens if we're pushing multiple heads? I suspect this will choose a head/revision arbitrarily - maybe depending on the -r arguments to hg push.

I think we need to validate that the outgoing revs are in a single DAG head and we should then pick the rev that is the DAG head.

Please add test coverage for multiple -r arguments and -r arguments that resolve to multiple heads.

101

Nit: what is --create?

294

Strictly speaking, we should probably wrap exchange._pushdiscoverybookmarks so other extensions can get involved. But I think this is fine.

This revision now requires changes to proceed.Mar 23 2018, 2:56 PM
pulkit updated this revision to Diff 7286.Mar 26 2018, 7:47 AM
pulkit edited the summary of this revision. (Show Details)

A gentle reminder for reviewing this series. If this config option gets in, we can use it in infinitepush extension too where for now we have overridden -B flag in a hacky way.

indygreg accepted this revision.Apr 11 2018, 1:29 PM

Looks good!

hgext/remotenames.py
113

Nit: "exist". This can be fixed in flight.

This revision is now accepted and ready to land.Apr 11 2018, 1:29 PM
smf added a subscriber: smf.Apr 11 2018, 1:32 PM

Looks good!

I'm very heavily against this direction. Changing the behavior of push (even in this extension) is something I've always considered outside the scope of remotenames. Having another extension that changes push behavior (e.g. bookmark-push) is where I think this should go so that remotenames is just that: keeping track of remote names.

In D2873#52025, @smf wrote:

Looks good!

I'm very heavily against this direction. Changing the behavior of push (even in this extension) is something I've always considered outside the scope of remotenames. Having another extension that changes push behavior (e.g. bookmark-push) is where I think this should go so that remotenames is just that: keeping track of remote names.

I think there's room for this feature to live outside of remotenames. But currently I think it is the best place for it, since remotenames is the closest thing we have to... tracking remote names. We can always alias the old config option in the future if we move this functionality elsewhere.

smf added a comment.Apr 11 2018, 5:39 PM
In D2873#52025, @smf wrote:

Looks good!

I'm very heavily against this direction. Changing the behavior of push (even in this extension) is something I've always considered outside the scope of remotenames. Having another extension that changes push behavior (e.g. bookmark-push) is where I think this should go so that remotenames is just that: keeping track of remote names.

I think there's room for this feature to live outside of remotenames. But currently I think it is the best place for it, since remotenames is the closest thing we have to... tracking remote names. We can always alias the old config option in the future if we move this functionality elsewhere.

One of the biggest regrets I have about the original remotenames, is the modifying of push (and some default) behavior. The --to is small enough (and I guess fine enough) for now but I absolutely and strongly believe that all the other behavior modifications should stay in an out-of-core repo for now. My goal is to split my remotenames repo to be based off of core's remotenames (basically only having the behavior changing patches there).