3 ms·

Not that I think submodules are great, but they can be used while still maintaining atomicity. It's just that the atomic update happens when updating the subm

by chrsig 4y ago

Not that I think submodules are great, but they can be used while still maintaining atomicity. It's just that the atomic update happens when updating the submodule commit in the parent project. This isn't any different than how say a b+tree (or other persistent data structures) rewrite their nodes from the leaf to the root, but leave non-involved subtrees as they were. There winds up being a lot of activity on the superproject that amounts to just updating its submodules, but the commit log for it becomes a linearized history of stable/compatible commit versions. There's definitely room for improvement wrt usability, but the claim that git has No atomicity across subprojects doesn't ring true to me

mdaniel 4y ago
I would pay $20 if git would disallow committing from within the submodule directory (single source of truth), because it makes it so easy to forget a git push from within that submodule and now "works on my machine," but "special wtf edition!"
- tedmiston 4y ago
  Are you saying submodule SHA was updated in the parent repo, but the new submodule commit which the parent repo is now pointing to was never pushed? I haven't experienced that scenario before but it seems like there'd be an obvious git error?
  - mdaniel 4y ago
    No, the opposite: git clone --recursive some/repo.git cd repo/subrepo sed -i"" s/hello/goodbye/ README.md git commit -am 'lololo' cd .. git commit -am'subrepo with *local* sha reference' git status # everything is clean! now that I know that can happen, running `git submodule foreach git status` will surface the "your branch is ahead of" magic text that indicates what has gone on, but it would be tons better if the system understood what was happening and didn't allow such a bad outcome
- pflanze 4y ago
  You could put a failing script (printing a message and exit 1) at .git/hooks/pre-commit in the submodule[1] (note that this is by-passed if you give --no-verify to git commit). Or you could put a script at .git/hooks/pre-push.sample in the parent repo (untested) that verifies if all commits in submodules are in the respective upstreams. I guess having that functionality in the core as a warning might not be a bad idea (I'm not a Git developer, you'll have to ask them). [1] or rather ../.git/modules/"$submodulename"/hooks/pre-commit, depending on how the submodule was added
  - mdaniel 4y ago
    Last I checked, one cannot write any such silliness during clone, so it would require documentation or something out of band to fix it on every junior developer's workstation, and thus doesn't help as much as if there was a `git config --global commit.allowSubsubmodle false` or whatever > Or you could put a script at .git/hooks/pre-push.sample in the parent repo (untested) that verifies if all commits in submodules are in the respective upstreams (a) those scripts are most certainly not called .sample (b) it was fast enough to set up a local test case and (as expected) each repo (outer and "inner" submodule) carry their own git hook setups and `echo "exit 1" > .git/hooks/pre-commit` does stop top level commits but does nothing for the inner repos
    - pflanze 4y ago
      > .sample Yes, I carelessly copy-pasted the path. And yes, as I said it would probably be a good idea to have a feature like that in the core. -- Ah, I see the other reply, so it's done. I generally recommend asking such questions on #git on IRC, someone will know the answer if a feature already exists.
- slavik81 4y ago
  I've convinced that the real problem with submodules is basically the UI. In particular, the defaults are terrible. You can ask it to block pushing if there are unpushed submodule commits with: git config push.recurseSubmodules check Or you can make it push automatically by replacing "check" with "on-demand". You may also find it helpful to make various commands automatically apply to submodules with: git config submodule.recurse true
  - mdaniel 4y ago
    Thank you, that push.recurseSubmodules=check is the knob I was looking for, and wish it were the default I got excited about the submodule.recurse=true one, but at least for "git status" it did not descend into the submodule the same way that "git submodule foreach git status" does

by chrsig 4y ago

mdaniel 4y ago

I would pay $20 if git would disallow committing from within the submodule directory (single source of truth), because it makes it so easy to forget a git push from within that submodule and now "works on my machine," but "special wtf edition!"

tedmiston 4y ago
Are you saying submodule SHA was updated in the parent repo, but the new submodule commit which the parent repo is now pointing to was never pushed? I haven't experienced that scenario before but it seems like there'd be an obvious git error?
- mdaniel 4y ago
  No, the opposite: git clone --recursive some/repo.git cd repo/subrepo sed -i"" s/hello/goodbye/ README.md git commit -am 'lololo' cd .. git commit -am'subrepo with *local* sha reference' git status # everything is clean! now that I know that can happen, running `git submodule foreach git status` will surface the "your branch is ahead of" magic text that indicates what has gone on, but it would be tons better if the system understood what was happening and didn't allow such a bad outcome
pflanze 4y ago
You could put a failing script (printing a message and exit 1) at .git/hooks/pre-commit in the submodule[1] (note that this is by-passed if you give --no-verify to git commit). Or you could put a script at .git/hooks/pre-push.sample in the parent repo (untested) that verifies if all commits in submodules are in the respective upstreams. I guess having that functionality in the core as a warning might not be a bad idea (I'm not a Git developer, you'll have to ask them). [1] or rather ../.git/modules/"$submodulename"/hooks/pre-commit, depending on how the submodule was added
- mdaniel 4y ago
  Last I checked, one cannot write any such silliness during clone, so it would require documentation or something out of band to fix it on every junior developer's workstation, and thus doesn't help as much as if there was a `git config --global commit.allowSubsubmodle false` or whatever > Or you could put a script at .git/hooks/pre-push.sample in the parent repo (untested) that verifies if all commits in submodules are in the respective upstreams (a) those scripts are most certainly not called .sample (b) it was fast enough to set up a local test case and (as expected) each repo (outer and "inner" submodule) carry their own git hook setups and `echo "exit 1" > .git/hooks/pre-commit` does stop top level commits but does nothing for the inner repos
  - pflanze 4y ago
    > .sample Yes, I carelessly copy-pasted the path. And yes, as I said it would probably be a good idea to have a feature like that in the core. -- Ah, I see the other reply, so it's done. I generally recommend asking such questions on #git on IRC, someone will know the answer if a feature already exists.
slavik81 4y ago
I've convinced that the real problem with submodules is basically the UI. In particular, the defaults are terrible. You can ask it to block pushing if there are unpushed submodule commits with: git config push.recurseSubmodules check Or you can make it push automatically by replacing "check" with "on-demand". You may also find it helpful to make various commands automatically apply to submodules with: git config submodule.recurse true
- mdaniel 4y ago
  Thank you, that push.recurseSubmodules=check is the knob I was looking for, and wish it were the default I got excited about the submodule.recurse=true one, but at least for "git status" it did not descend into the submodule the same way that "git submodule foreach git status" does