On 04/05, Jacob Keller wrote: > On Fri, Mar 31, 2017 at 5:19 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > Brandon Williams wrote: > > > >> Teach push --recurse-submodules to propagate push-options recursively to > >> the pushes performed in the submodules. > > > > Some time in the future we may want "push --recurse-submodules" to do a > > dry run pass before doing the final push, so that if it is known that > > some of the pushes wouldn't succeed (e.g. due to not being > > fast-forward, or the server not being reachable, or the server not > > supporting push options) then git could stop early instead of some > > succeeding and some failing. > > > > But that's a larger and separate change from this one. Users of push > > --recurse-submodules today know they are effectively asking for > > multiple pushes that are not guaranteed to succeed or fail together. > > > > If you want it to be truly atomic it will require more effort than the > above. Suppose that you do a dry-run first, and then find out > everything will succeed. After this, you do the real pushes. But in > between these two commands something could have changed, and you could > still end up with a non-atomic set of pushes. > > I think that's ok and better than before, but it should be noted that > you stll don't guarantee that all the pushes succeed or fail together. > > I'm really not sure if you even can make these pushes work atomically > considering they are going to different hosts. Yeah, really it becomes impossible to have submodules pushed to multiple hosts in an atomic way. I think what Jonathan is mentioning is a way to ensure that the options and everything are supported by the server you are communicating with (for each submodule), though you could just run an explicit dry-run yourself. If you truly wanted the superproject and all submodules updated in an atomic way you would need some other server side service (e.g. gerrit) to ensure that it was done properly. -- Brandon Williams