Hi, Romuald Brunet wrote: > On ven., 2017-03-24 at 12:29 -0700, Junio C Hamano wrote: >> Jeff King <peff@xxxxxxxx> writes: >>> My one question would be whether people would want this to actually be >>> specific to a particular remote, and not just on for a given repository >>> (your "site-specific" in the description made me think of that). In that >>> case it would be better as part of the remote.* config. >> >> Yeah, I had the same reaction. >> >> Conceptually, this sits next to remote.*.push that defines which set >> of refs are sent by default, and remote.<name>.pushAtomic does make >> sense. If (and only if) it turns out to be cumbersome for somebody >> to set the configuration for each and every remote, it is OK to also >> add push.atomic to serve as a fallback for remote.*.pushAtomic, I >> would think, but adding only push.atomic feels somewhat backwards. > > Thanks for your feedback > > I'm mostly using single remotes that's why I didn't even think of making > it configurable per remote. But you're right that makes more sense. > > I'll try to make that modification to the patch. > > As for my use case: I'd like to use default atomic pushes when pushing a > new tag among our stable branch, but inevitably forgetting to rebase > beforehand. Therefore pushing a "dangling" commit/tag Making it per-remote would also address my concern about scripts. Existing scripts may be using git push $url $refs and relying on the push to partially succeed even when some refs cannot be fast-forwarded. (For example, I had such a script that did git push my-mirror refs/remotes/origin/*:refs/heads/* git push my-mirror +origin/pu:pu because the first command would fail to update pu, and then the second command would clean up after it.) A configuration that globally changes the effect of "git push" to mean "git push --atomic" would break such scripts. A per-remote configuration is tightly enough scoped to not be likely to cause unrelated breakage for users that run scripts written by others. Thanks and hope that helps, Jonathan