[PATCH] [v2] outgoing: respect ":pushurl" paths (issue5365)
7895pulkit at gmail.com
Sat Nov 4 05:34:04 EDT 2017
You can use the `--flag` option of `hg email` to add email flags like V2.
On Sat, Nov 4, 2017 at 11:48 AM, Yuya Nishihara <yuya at tcha.org> wrote:
> On Fri, 3 Nov 2017 14:07:54 -0700, Hollis Blanchard wrote:
>> # HG changeset patch
>> # User Hollis Blanchard <hollis_blanchard at mentor.com>
>> # Date 1509731952 25200
>> # Fri Nov 03 10:59:12 2017 -0700
>> # Branch stable
>> # Node ID a952cae0303fa38d1b246561704071d41bbfa1ea
>> # Parent f445b10dc7fb3495d24d1c22b0996148864c77f7
>> [v2] outgoing: respect ":pushurl" paths (issue5365)
>> Make 'hg outgoing' respect "paths.default:pushurl" in addition to
>> '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'.
> I heard from Greg that the current behavior was intentional.
> Just to be clear, I'm not against this patch, but this will be a breaking
> change for some users.
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
More information about the Mercurial-devel