[githelp] Relative submodule paths..
I've been trying to clean out the pull requests for the boost super-project and I ran into this one <https://github.com/boostorg/boost/pull/33>. And I don't really know if it makes sense, as I have personally not done a fork of the super-project. Is it a real problem? Should we change all the sub-project references? If yes, what are the likely impacts on others and existing release processes? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 2/6/2015 4:25 PM, Rene Rivera wrote:
I've been trying to clean out the pull requests for the boost super-project and I ran into this one <https://github.com/boostorg/boost/pull/33>. And I don't really know if it makes sense, as I have personally not done a fork of the super-project.
Is it a real problem? Should we change all the sub-project references? If yes, what are the likely impacts on others and existing release processes?
I assume a relative submodule URL refers to the path off of the super-project's URL. As long as the super-project fork is done from within Github the pull request is correct. The way you have it designated works well if someone forks the super-project and then forks all the sub-projects to URLs relative to the forked super-project. I think this is an unlikely scenario. A forked super-project will almost certainly want to refer to the existing sub-projects.
On 2015-02-06 16:25, Rene Rivera wrote:
I've been trying to clean out the pull requests for the boost super-project and I ran into this one <https://github.com/boostorg/boost/pull/33>. And I don't really know if it makes sense, as I have personally not done a fork of the super-project.
Is it a real problem? Should we change all the sub-project references? If yes, what are the likely impacts on others and existing release processes?
This issue annoyed me when I forked the super project. I'm slightly surprised that the proposed fix works, but if it does, then it seems reasonable and unlikely to break anything that was previously working... John Bytheway
On 8 February 2015 at 22:44, John Bytheway <jbytheway+boost@gmail.com> wrote:
On 2015-02-06 16:25, Rene Rivera wrote:
I've been trying to clean out the pull requests for the boost super-project and I ran into this one <https://github.com/boostorg/boost/pull/33>. And I don't really know if it makes sense, as I have personally not done a fork of the super-project.
Is it a real problem? Should we change all the sub-project references? If yes, what are the likely impacts on others and existing release processes?
This issue annoyed me when I forked the super project. I'm slightly surprised that the proposed fix works, but if it does, then it seems reasonable and unlikely to break anything that was previously working...
There's no need to change the submodule paths, all you have to do is set the super-project's origin to point to boostorg/boost. The pull request will prevent anyone from using a different location for the submodules.
On Sun, Feb 8, 2015 at 5:20 PM, Daniel James <dnljms@gmail.com> wrote:
On 2015-02-06 16:25, Rene Rivera wrote:
I've been trying to clean out the pull requests for the boost super-project and I ran into this one <https://github.com/boostorg/boost/pull/33>. And I don't really know if it makes sense, as I have personally not done a fork of the super-project.
Is it a real problem? Should we change all the sub-project references? If yes, what are the likely impacts on others and existing release
On 8 February 2015 at 22:44, John Bytheway <jbytheway+boost@gmail.com> wrote: processes?
This issue annoyed me when I forked the super project. I'm slightly surprised that the proposed fix works, but if it does, then it seems reasonable and unlikely to break anything that was previously working...
There's no need to change the submodule paths, all you have to do is set the super-project's origin to point to boostorg/boost. The pull request will prevent anyone from using a different location for the submodules.
OK, good to know. But.. How does one do that? And.. Where do we have that documented for users who want to do that? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail
On 9 February 2015 at 03:01, Rene Rivera <grafikrobot@gmail.com> wrote:
On Sun, Feb 8, 2015 at 5:20 PM, Daniel James <dnljms@gmail.com> wrote:
On 2015-02-06 16:25, Rene Rivera wrote:
I've been trying to clean out the pull requests for the boost super-project and I ran into this one <https://github.com/boostorg/boost/pull/33>. And I don't really know if it makes sense, as I have personally not done a fork of the super-project.
Is it a real problem? Should we change all the sub-project references? If yes, what are the likely impacts on others and existing release
On 8 February 2015 at 22:44, John Bytheway <jbytheway+boost@gmail.com> wrote: processes?
This issue annoyed me when I forked the super project. I'm slightly surprised that the proposed fix works, but if it does, then it seems reasonable and unlikely to break anything that was previously working...
There's no need to change the submodule paths, all you have to do is set the super-project's origin to point to boostorg/boost. The pull request will prevent anyone from using a different location for the submodules.
OK, good to know. But.. How does one do that? And.. Where do we have that documented for users who want to do that?
I don't think we have any documentation either way. We could put something on the wiki, but the chances are most people wouldn't find it. Someone who wants to maintain a fork of the super-project will need to know how to handle remotes, otherwise they'll probably just get in a mess. Git's submodule system is fiddly enough for simple cases. But if you want to write a page, here's the basics: How it's done depends on the software you use. If you use the github command line client, and clone from boostorg then fork using 'hub fork', it will keep 'boostorg' as the 'origin' remote, and your account's remote will be named after your username, which is what's wanted. If not, you can clone from boostorg, then add the fork (untested): git clone https://github.com/boostorg/boost.git git remote add -f danieljames https://github.com/danieljames/boost.git git checkout danieljames/some-branch -b some-branch Or clone from the fork, and then add origin (also untested): git clone -o danieljames -b some-branch https://github.com/danieljames/boost.git git remote add origin https://github.com/boostorg/boost.git If someone wants to publish a fork for others to use without doing this, then they're going to have to mess around with the modules anyway, I don't think it's much work to do a search and replace.
participants (4)
-
Daniel James -
Edward Diener -
John Bytheway -
Rene Rivera