On 2024-03-13 at 22:58:58, Junio C Hamano wrote: > Christopher Lindee <christopher.lindee@xxxxxxxxxxx> writes: > > This changeset proposes to address this issue by adding an option to `push` and > > `send-pack` that, when specified, will send refs where the old-oid and new-oid > > "where" -> "even if" > > > are identical - instead of silently skipping these refs. The first commit > > introduces the `--send-up-to-date` option to toggle this behavior, while the > > second commit updates the commands to output an `(up-to-date)` notice for each > > branch with an identical old-oid and new-oid. > > > > Notably, the `--force` option will not send a ref when the remote is up-to-date. > > And it makes sense *not* to update `--force` to do the no-op push, > becaues you may not want to (accidentally) force push a ref that > does not fast-forward. As I already said, tying this with use of > the "-o" option is not sufficient. So I agree we may want a new > option to trigger this behaviour. > > A radical counter-proposal for the design is to update the client > side to do this unconditionally, without needing any new option. I'm not sure that would be a great idea. Since it's a push, that will trigger authentication, which may prompt the user (e.g., for a password or token or for a YubiKey touch with FIDO2 SSH) and which they might be able to easily avoid. As a server operator, I also expect that there are people doing lots of needless attempts at pushing in automated systems (because with enough users, there will be at least some who do bizarre or inefficient things), and I would prefer to avoid serving those requests if I don't need to. (For example, for us, reference updates need to go through a distributed commit protocol to update multiple replicas of the repository, and if there's no ref updates, then we cut out multiple services which we don't need to contact.) Note also that no-op ref updates cannot be simply omitted on the server side because we need to verify that the old value for the ref is correct, or we need to reject the operation as out of date. While it is _unlikely_ that the ref has changed since we fetched it from the server, it's not guaranteed, especially if there's an expensive `pre-push` hook. I do think the proposed change is valuable, though, and I'm in favour of it with a suitable option. -- brian m. carlson (they/them or he/him) Toronto, Ontario, CA
Attachment:
signature.asc
Description: PGP signature
