[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