I am in the process of setting up some third-party subrepositories under a Mercurial repository. One subrepo is another Mercurial repo hosted on Bitbucket.
Since it is a public repo, and I am not a contributor to it, I don't wish to push back to it. However I would like to still have the repository automatically cloned when I clone the parent repository. For one thing, I'd like to have access to the collective history of the subrepository so I can see what may or may not have changed over time.
So, I made an entry in the parent repo's .hgsub file as follows:
thesubrepo = https://bitbucket.org/user/repo
and cloned the repo using
$ hg clone https://bitbucket.org/user/repo thesubrepo
I made a commit to record the subrepo state. I then went to push my parent repo back to it's server (Kiln) only to discover that it was trying to push the subrepo I back to the Bitbucket server. The push to the Bitbucket subrepository appears to not do anything, though.
I did not observe this behaviour when I made a Git subrepo in the same manner (hosted on Git hub) using an entry in .hgsub like this
abc = [git]git://github.com/xyz/abc
Is it best for me just to do this by not setting up a subrepository, and just let Mercurial store the files as files? Or (preferably) is there some setting somewhere that I can use to tell Mercurial to never actually push the contents of this subrepo back to it's source location?
I'd rather be able to configure it to only push those subrepos manually, so if anyone can shed some light on this, I would appreciate it.
I found a reference to commitsubrepos = no in another stack overflow answer, which as far as i can tell is about commits, and not pushes of sub repositories. I then looked this up on the mercurial website, in the hope there might be some reference to a setting pertaining to pushing subrepos, but... no
You cannot (currently, as of version 2.0) ask Mercurial to not push subrepositories.
The fundamental problem is that Mercurial must ensure that you have a consistent state on the remote repository when you push. It would be unsafe if you could push back to Kiln and then have a changeset there that references a revision on Bitbucket that isn't there. Mercurial doesn't know if a changeset you have locally is published or if you created it — so it has to (try to) push.
We're currently working on a concept called phases. With that in place, Mercurial will begin tracking if a changeset is created locally or already published. That can be used for subrepositories too: if there are only changesets in the "public" phase in a subrepo, then there's no need to try pushing!