Re: [PATCH 0/2] Optionally support push options on up-to-date branches

[Christopher Lindee <christopher.lindee@webpros.com>]

brian m. carlson writes:

> On 2024-03-13 at 22:58:58, Junio C Hamano wrote:
> > Christopher Lindee <christopher.lindee@webpros.com> 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.