The following output is pretty self explanatory. But just to be clear, I was expecting "hg outgoing" to check ssh://hg@bitbucket.org/rw_grim/pidgin and not ssh://hg@bitbucket.org/pidgin/main $ head -n 5 .hg/hgrc # example repository config (see "hg help config" for more info) [paths] default = ssh://hg@bitbucket.org/rw_grim/pidgin upstream = ssh://hg@bitbucket.org/pidgin/main upstream:pushurl = ssh://hg@bitbucket.org/rw_grim/pidgin $ hg outgoing upstream comparing with ssh://hg@bitbucket.org/pidgin/main searching for changes
pushurl and pushrev aren't integrated with the outgoing command yet.
(adding Greg)
There was some discussion of whether `hg outgoing` should use the default URL or the push URL in the thread at https://www.mercurial-scm.org/pipermail/mercurial-devel/2014-September/062069.html (this is discussing a patch series that was a precursor to what eventually landed). Essentially, a case can be made for both approaches. Points in favor of "outgoing" using the push url: * outgoing and push are related operations * you probably want outgoing to run against the same repo you will push to Points in favor of "outgoing" using the main url: * push url may require different authentication from main url (e.g. enter SSH passphrase), making `hg outgoing` more difficult to use * company may have a central read-write server and multiple read-only servers and may not wish for excessive commands to hit central read-write due to load reasons Presumably, the main URL and the push URL refer to the same repository. Otherwise you should be using separate paths. That means the point about ensuring you run against the same repo you push to is somewhat nullified. Although it appears the bug reporter didn't do this, as their "upstream:pushurl" actually refers to the "default" path. While I personally wouldn't "mix the URLs" like that, it is a perfectly valid configuration. It does raise interesting implications for the behavior of `hg outgoing` given that a path's URLs actually refer to different repositories. That's an edge case I hadn't considered: I always assumed the URLs for a path would refer to the same repository, likely only differentiated by protocol (e.g. https:// for read, ssh:// for push). Therefore, what `hg outgoing` connected to didn't really matter since it ultimately talked to the same repo.
Hmm, makes some sense. We'll probably need to document that since historically "default-push" paths were used for both outgoing and push.
To be clear, I want the upstream path to *NOT* be able to push. That is our central repository where pull requests are merged via Bitbucket. Pushing to that directly is saved for extreme cases of which nothing is coming to mind right now. At any rate, what I'm trying to do is protect the repository from me accidentally pushing to it without review and would like to have a way for my team to do the same.
> what I'm trying to do is protect the repository from me accidentally > pushing to it I understand your use case, I sometimes set :pushurl to file:///dev/null. But Gregory pointed out there was a reason to not use :pushurl for outgoing, which also makes sense. So I think documenting the current behavior is the way to go.
Bug was inactive for 150 days, archiving
I agree that the current behavior (ignoring default:pushurl) doesn't make sense. 'hg outgoing' has always meant "what will happen if I push?", and it's still documented that way: Show changesets not found in the specified destination repository or the default push location. These are the changesets that would be pushed if a push was requested. Also, note that "default-push" is respected by 'hg outgoing', while "default:pushurl" is not! In the unlikely case that 'hg outgoing' storms are flooding Mozilla's SSH server, it sounds like their needs would be satisfied by their developers running 'hg outgoing default' (or alias it).
Created attachment 1981 [details] testcase Attaching (currently failing) testcase.
Created attachment 1982 [details] proposed fix Attaching a fix.
(In reply to Hollis Blanchard from comment #10) Please submit patches to the mercurial-devel mailing list. See <https://www.mercurial-scm.org/wiki/ContributingChanges>.
Fixed by https://mercurial-scm.org/repo/hg/rev/0ebd94ac56d1 Hollis Blanchard <hollis_blanchard@mentor.com> outgoing: respect ":pushurl" paths (issue5365) Make 'hg outgoing' respect "paths.default:pushurl" in addition to "paths.default-push". 'hg outgoing' has always meant "what will happen if I run 'hg push'?" and it's still documented that way: Show changesets not found in the specified destination repository or the default push location. These are the changesets that would be pushed if a push was requested. If the user uses the now-deprecated "paths.default-push" path, it continues to work that way. However, as described at https://bz.mercurial-scm.org/show_bug.cgi?id=5365, it doesn't behave the same with "paths.default:pushurl". Why does it matter? Similar to the bugzilla reporter, I have a read-only mirror of a non-Mercurial repository: upstream -> imported mirror -> user clone ^-----------------------/ Users push directly to upstream, and that content is then imported into the mirror. However, those repositories are not the same; it's possible that the mirroring has either broken completely, or an import process is running and not yet complete. In those cases, 'hg outgoing' will list changesets that have already been pushed. Mozilla's desired behavior described in bug 5365 can be accomplished through other means (e.g. 'hg outgoing default'), preserving the consistency and meaning of 'hg outgoing'. (please test the fix)