Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Edit, much later: As of Git 1.7.7, <code>git-push</code> now has a <code>--recurse-submodules=check</code> option, which refuses to push the parent project if any submodule commits haven't been pushed to their remotes. It doesn't appear that a corresponding <code>push.recurseSubmodules</code> config parameter has been added yet. This of course doesn't entirely address the problem - a clueless user could still push without the check - but it's quite relevant!</p> <p>I think the best approach, rather than examining each individual commit, is to look at the diff across all of the pushed commits: <code>git diff &lt;old&gt; &lt;new&gt;</code>. You don't want to look at the whole diff though, really; it could be enormous. Unfortunately, the git-submodule porcelain command doesn't work in bare repos, but you should still be able to quickly examine <code>.gitmodules</code> to get a list of paths (and maybe URLs). For each one, you can <code>git diff &lt;old&gt; &lt;new&gt; -- path</code>, and if there is a diff, grab the new submodule commit. (And if you're worried about a 000000 old commit possibility, you can just use <code>git show</code> on the new one, I believe.)</p> <p>Once you get all that taken care of, you've reduced the problem to checking whether given commits exist in given remote repositories. Unfortunately, as it looks like you've noticed, that's not straightforward, at least <a href="https://stackoverflow.com/questions/3418674/bash-shell-script-function-to-verify-git-tag-or-commit-exists-and-has-been-pushed">as far as I know</a>. Keeping local, up-to-date clones is probably your best bet, and it sounds like you're good there.</p> <p>By the way, I don't think the caching is going to be relevant here, since the update hook is once per ref. Yes, you could do this in a pre-receive hook, which gets all the refs on stdin, but I don't see why you should bother doing more work. It's not going to be an expensive operation, and with an update hook, you can individually accept or reject the various branches being pushed, instead of preventing <em>all</em> of them from being updated because only one was bad.</p> <p>If you want to save some trouble, I'd probably just avoid parsing the gitmodules file, and hardcode a list into the hook. I doubt your list of submodules changes very often, so it's probably cheaper to maintain that than to write something automated.</p>
    singulars
    1. This table or related slice is empty.
    1. POWhat is the best way to write a git update hook that rejects invalid submodule commits?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USCommunity
    1. USCascabel
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POWhat is the best way to write a git update hook that rejects invalid submodule commits?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COThanks for the comments. I think you are misunderstanding me about (2). I understand that the update hook is called once per branch being pushed and that you get the oldref and newref as well. I was just using git rev-list to get a list of the actual commits being pushed, which seemed kinda necessary due to certain situations when oldref is 0000000000, though maybe I can work around that. Otherwise, thanks for the tips... especially looking at just the diff of each submodule path. That should make things easier.
      singulars
      1. PO
      1. USSebastian Celis
    2. CO@Sebastian: Oh, gotcha, no wonder I was confused. Still, I do think (despite the 00000 possibility) that diffing is going to be a whole lot easier. I'll try and edit to reflect this.
      singulars
      1. PO
      1. USCascabel
    3. COAccepting this answer as no one was able to provide any better advice. It's not a perfect solution, and misses situations where the user is pushing 5 commits, the 3rd of which broke a submodule which was then fixed in commit 4. It also isn't great at handling situations where the submodule URL changes. But, this solution is probably "good enough". Thanks!
      singulars
      1. PO
      1. USSebastian Celis
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload