[Bug 5668] New: Push / update on subrepos: reduce changesets based on connectivity graph
mercurial-bugs at mercurial-scm.org
mercurial-bugs at mercurial-scm.org
Sun Aug 27 10:08:00 UTC 2017
https://bz.mercurial-scm.org/show_bug.cgi?id=5668
Bug ID: 5668
Summary: Push / update on subrepos: reduce changesets based on
connectivity graph
Product: Mercurial
Version: 4.3
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: feature
Priority: wish
Component: Mercurial
Assignee: bugzilla at mercurial-scm.org
Reporter: dinumarina at gmail.com
CC: mercurial-devel at mercurial-scm.org
After bashing my head a few hours thinking I had made an error, I realized that
hg has the lazy behavior of pushing subrepositories in their entirety, even if,
say, hg push -b <branch_name> is used.
Now, say I have a repo with a "stable" branch, that has a number of dependency
subrepos that have a heapload of branches and changesets, but the pattern is
that the "stable" branch in the root repo will only reference "stable" branches
of the components.
In the case of a push operation (or conversely a recursive update/pull subrepo
on the other side) that specifies a subset (such as -b), I think it's possible
to establish the referred subrepo revisions and regress them to restrict
outgoing changes to only those that would be connectable in the subrepo to
transfer. That is, strictly the revisions to insure a proper update to the
branch tip on the receiving end.
Alternately, at least a feature to specify the subrepo branch to push, that
would work by convention (i.e. an extension of -b that also applies to
subrepos).
Either of these would be immensely helpful, are there any plans to do something
like this in the near future?
Thanks,
Dinu
--
You are receiving this mail because:
You are on the CC list for the bug.
More information about the Mercurial-devel
mailing list