Isn't a bad practice to commit/push changes from a submodule repository?

Question

The full question would be:

Isn't a bad practice to commit/push changes from a submodule repository instead of cloning it in a separate, independent repo and doing all the changes there?

I'm trying to convince some of my colleagues that the 'cleaner' and best way of adding changes to a submodule repository is to clone it in a separate repo, add the changes (add, commit, push) and then updating the submodule version in the 'host' project. However, my epic motivational speech on this matter had little impact on them, and I need extra argument ammunition to change their minds. For now, the main reasons that I have found are:

Submodule repositories point by definition to a commit, not to the latest version, so adding changes from a DETACHED_HEAD state is messy.
Conceptually, a submodule is a dependency.
Cloning the submodule repository in a separate place and doing there all the changes, then checking out the submodule to the new version implies little extra effort.

Is there any other arguments in favor (or against) this idea?

Thanks in advance!

Voted to close as primarily opinion based. It's up to your team. Personally, I'd stop bugging them over this. — user229044, Dec 01 '14 at 13:52
Ok, thanks anyway to meagar & @VonC for sharing their points of view. — Яois, Dec 02 '14 at 06:40

score 1 · Answer 1 · edited May 23 '17 at 11:50

1

I usually do my modification directly in the submodule directly, provided that:

I have the right to push to its upstream repo
for every push, I don't forget to go to the current parent repo of the submodule, add and command the new gitlink entry.

That allows me to test the submodule in the content of the parent repo which is using it.

edited May 23 '17 at 11:50

Community

1
1

answered Dec 01 '14 at 10:35

VonC

1,262,500
529
4,410
5,250

score 1 · Answer 2 · answered Dec 01 '14 at 13:56

I think you're wrong. Your method is inefficient and prone to error.

I commit changes from within the submodule because that is how I can fully test that the changes I'm introducing actually fulfill the need that prompted me to make changes. It lets me run my test suites and verify that nothing has broken in either the submodule or the app consuming it. It's needless inefficient to artificially erect barriers to this process.

Yes, perhaps in the wider world it might make sense for library code and application code to be worked on independently. Yes, this would prevent coupling. So does a modicum of thought during development. In practice, changes to library code are driven by needs in the application, and changes made to the library in isolation often don't work on the first try, requiring additional commits to the library.

The only way to avoid these downsides is to adhere strictly to the waterfall model and completely design both systems on paper before you write code, so that you know the changes you're introducing to the submodule are exactly the required changes. Even then, that only prevents some of the grief, it doesn't actually make a case for committing outside the submodule.

Isn't a bad practice to commit/push changes from a submodule repository?

2 Answers2