Submodule name mismatches between master and develop
Several submodules have different names on master and develop: - compute (libs/compute on develop) - couroutine2 (libs/coroutine2 on develop) - dll (libs/dll on develop) - qvm (libs/qvm on develop) - vmd (libs/vmd on develop) Should we normalize the names on develop? I think that after fixing .gitmodules, these submodules will appear as-if deinitialized, and would need a `git submodule update --init` to reappear under the new names. There are also libs/hana and libs/metaparse, which have consistent (although "wrong") names on both master and develop. Not sure if we need to bother with them.
On 8/4/17 05:44, Peter Dimov via Boost wrote:
Several submodules have different names on master and develop:
- compute (libs/compute on develop) - couroutine2 (libs/coroutine2 on develop) - dll (libs/dll on develop) - qvm (libs/qvm on develop) - vmd (libs/vmd on develop)
Should we normalize the names on develop?
I think that after fixing .gitmodules, these submodules will appear as-if deinitialized, and would need a `git submodule update --init` to reappear under the new names.
There are also libs/hana and libs/metaparse, which have consistent (although "wrong") names on both master and develop. Not sure if we need to bother with them.
I would prefer if we "fix" all of the names. Normalize those on develop and correct hana and metaparse. -- Michael Caisse Ciere Consulting ciere.com
Boost - Dev mailing list wrote
On 8/4/17 05:44, Peter Dimov via Boost wrote:
Several submodules have different names on master and develop:
- compute (libs/compute on develop) - couroutine2 (libs/coroutine2 on develop) - dll (libs/dll on develop) - qvm (libs/qvm on develop) - vmd (libs/vmd on develop)
Should we normalize the names on develop?
I think that after fixing .gitmodules, these submodules will appear as-if deinitialized, and would need a `git submodule update --init` to reappear under the new names.
There are also libs/hana and libs/metaparse, which have consistent (although "wrong") names on both master and develop. Not sure if we need to bother with them.
I would prefer if we "fix" all of the names. Normalize those on develop and correct hana and metaparse.
+1 I think I copied Metaparse's pull request that added itself as a submodule, and this is why Hana ended up wrong as well. I see no reason to keep it the way it is today. I can submit a PR for Hana if you want, but I guess it's simple for you to just address all of those issues at once? Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Submodule-name-mismatches-between-master-... Sent from the Boost - Dev mailing list archive at Nabble.com.
2017-08-04 14:44 GMT+02:00 Peter Dimov via Boost
Several submodules have different names on master and develop:
- compute (libs/compute on develop) - couroutine2 (libs/coroutine2 on develop) - dll (libs/dll on develop) - qvm (libs/qvm on develop) - vmd (libs/vmd on develop)
Should we normalize the names on develop?
I think that after fixing .gitmodules, these submodules will appear as-if deinitialized, and would need a `git submodule update --init` to reappear under the new names.
There are also libs/hana and libs/metaparse, which have consistent (although "wrong") names on both master and develop. Not sure if we need to bother with them.
What do I have to do as one of the maintainers in order to fix the issue?
Oliver Kowalke wrote:
2017-08-04 14:44 GMT+02:00 Peter Dimov via Boost
: Several submodules have different names on master and develop: ... Should we normalize the names on develop? ...
What do I have to do as one of the maintainers in order to fix the issue?
Nothing, it's a superproject issue.
On 4 August 2017 at 13:44, Peter Dimov via Boost
There are also libs/hana and libs/metaparse, which have consistent (although "wrong") names on both master and develop. Not sure if we need to bother with them.
I wouldn't bother. What the names are is mostly irrelevant, they're mainly used as internal identifiers. Having them change arbitrarily in the history is more likely to cause a problem than not following a naming convention. It's very easy for scripts to handle the names, and users aren't normally aware of them.
Boost - Dev mailing list wrote
On 4 August 2017 at 13:44, Peter Dimov via Boost <
boost@.boost
> wrote:
There are also libs/hana and libs/metaparse, which have consistent (although "wrong") names on both master and develop. Not sure if we need to bother with them.
I wouldn't bother. What the names are is mostly irrelevant, they're mainly used as internal identifiers. Having them change arbitrarily in the history is more likely to cause a problem than not following a naming convention. It's very easy for scripts to handle the names, and users aren't normally aware of them.
Not everything is about minimizing the risk for causing problems (especially when it's almost inexistent, like here). IMO, consistency is much more important, even if it's just for the sake of it because they're just internal names. I've asked Peter to change Hana and Metaparse as well on his PR: https://github.com/boostorg/boost/pull/158. Louis -- View this message in context: http://boost.2283326.n4.nabble.com/Submodule-name-mismatches-between-master-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 5 August 2017 at 20:43, Louis Dionne via Boost
Not everything is about minimizing the risk for causing problems (especially when it's almost inexistent, like here). IMO, consistency is much more important, even if it's just for the sake of it because they're just internal names. I've asked Peter to change Hana and Metaparse as well on his PR: https://github.com/boostorg/boost/pull/158.
Consistency for its own sake feels like a foolish consistency to me. It's a useful principle to avoid changing identifiers in persistent state, I've found that it is the kind of thing that can cause problems down the line, often in an unanticipated fashion.<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /> <table style="border-top: 1px solid #D3D4DE;"> <tr> <td style="width: 55px; padding-top: 13px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td> <td style="width: 470px; padding-top: 12px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Virus-free. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail" target="_blank" style="color: #4453ea;">www.avast.com</a> </td> </tr> </table><a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"></a></div>
On 8/4/2017 8:44 AM, Peter Dimov via Boost wrote:
Several submodules have different names on master and develop:
- compute (libs/compute on develop) - couroutine2 (libs/coroutine2 on develop) - dll (libs/dll on develop) - qvm (libs/qvm on develop) - vmd (libs/vmd on develop)
Should we normalize the names on develop?
Yes.
I think that after fixing .gitmodules, these submodules will appear as-if deinitialized, and would need a `git submodule update --init` to reappear under the new names.
Agreed.
There are also libs/hana and libs/metaparse, which have consistent (although "wrong") names on both master and develop. Not sure if we need to bother with them.
I think we should and all submodules should be normalized under their short name and not with libs/ preceding it.
participants (6)
-
Daniel James
-
Edward Diener
-
Louis Dionne
-
Michael Caisse
-
Oliver Kowalke
-
Peter Dimov