I think you want to solve a problem with Git that should be solved by some other process. As nothing prevents you from committing both local file modifications *and* submodule updates (in fact, it can be useful in a lot of cases), this becomes process related instead of tool related.
However, you want to use a screwdriver to handle nails. Have a review process, where other developers reject your commit if it contains anything but the submodule update. Have a CI machinery that enforces this. Or anything along these lines. Git is a powerful tool, but it won't solve all your problems. On Wed, May 24, 2017, 15:57 Xen <l...@xenhideout.nl> wrote: > So next question. > > I now have a bit of a background script that will verify that there are > modules that need a commit in the parent repository and it will also > verify at present that there are no staged changes as yet in the parent > repository so that it can create an "atomic commit" of that submodule > SHA change. > > So currently the script bails if there are staged changes > > (I grep on "^[MADRC]." to see if there are staged changes in the index) > > because I don't want to conflate other stuff in this automatic commit, > if anything might be the case. > > Now I can easily stash -u and the only thing left in the repository will > actually be modifications to the sub-modules, especially if I use > --ignore-submodules=dirty > > I mean to say it gives the exact output I need. > > However an automatic script stashing and committing and then popping > seems to be not very safe. > > If you were to happen to be editing a file, weird stuff might happen. > > Now that I think of it preventing git operations would not solve it.... > > A file might get deleted by git while the filehandle was still open by > an editor and then the file would be reinstated by git but it would be a > different file... > > Vim would say: > > "testfile" > WARNING: The file has been changed since reading it!!! > Do you really want to write to it (y/n)? > > Not terribly disastric. > > But in any case more dangerous would be you issuing a git command while > the script is also issuing a git command. > > Is there, still, > > any way to actually prevent something else from issuing git commands to > my repository? > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
