brian m. carlson writes: > 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.) I agree. I could easily see a nightly cron that backs up all refs to a server that would then trigger server-side action. I'm curious about authentication though, when I did a packet trace on an up-to-date ref, I noticed it ended with: push< ... push< 0000 push> 0000 This suggests that something is sent back to the server. Does that null entry not require authentication? > 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. Regards, Chris.
