Jonathan Nieder [off-list ref] writes:
quoted
quoted
- if (finish_command(&child)) {
- /*
- * The information that push negotiation provides is useful but
- * not mandatory.
- */
- warning(_("push negotiation failed; proceeding anyway with push"));
- }
Perhaps like "optional ancestry negotiation failed---pushing
normally" or some phrasing that assures the users that pushing
without negotiation is perfectly normal?
The question is what the user will do with this information.
Will they contact the service provider to ask them to turn on push
negotiation?
Will they turn off push negotiation because they don't want to waste a
round trip?
Does what they will do depend on _why_ push negotiation failed? If it
failed because the server didn't declare the capability and the user
has set push.negotate to true to represent "I want to live in the
future by using push negotiation wherever it's available", then the
message is noise. If it failed due to a bug, then the message is more
relevant to the user --- e.g., should we use a different exit status
to distinguish between these two cases?
I was hoping that the "child" command being run there gives enough
clue before the warning message so that the user would already know
(that is where my "assures the users" primarily comes from---even we
cannot hide that the negotiation poll has failed, the users would be
helped by being told that it is OK).
If "child" does not give enough clue to this codepath (via the exit
code) or to the end user (via error messages), we probably would
want to fix that for that approach to work.
Jonathan Nieder [off-list ref] writes:
quoted
quoted
quoted
- if (finish_command(&child)) {
- /*
- * The information that push negotiation provides is useful but
- * not mandatory.
- */
- warning(_("push negotiation failed; proceeding anyway with push"));
- }
Perhaps like "optional ancestry negotiation failed---pushing
normally" or some phrasing that assures the users that pushing
without negotiation is perfectly normal?
The question is what the user will do with this information.
Will they contact the service provider to ask them to turn on push
negotiation?
Will they turn off push negotiation because they don't want to waste a
round trip?
Does what they will do depend on _why_ push negotiation failed? If it
failed because the server didn't declare the capability and the user
has set push.negotate to true to represent "I want to live in the
future by using push negotiation wherever it's available", then the
message is noise. If it failed due to a bug, then the message is more
relevant to the user --- e.g., should we use a different exit status
to distinguish between these two cases?
I was hoping that the "child" command being run there gives enough
clue before the warning message so that the user would already know
(that is where my "assures the users" primarily comes from---even we
cannot hide that the negotiation poll has failed, the users would be
helped by being told that it is OK).
If "child" does not give enough clue to this codepath (via the exit
code) or to the end user (via error messages), we probably would
want to fix that for that approach to work.
The idea of this patch is to treat it like a user wanting to use
protocol v2 - if the remote doesn't support it, then the user is
perfectly fine falling back, and any extra message would be noise
because the user wouldn't take action on it anyway.
If we think that the user needs to know when push negotiation fails (for
example, if we think "the user enabled it so the user expects it to
happen"), then I agree that we should leave the warning messages in and
also print a message saying that push is still happening anyway (which
was the approach in the original patch set), and maybe update the
message to something like Junio suggested [1] to clarify what's going
on. But I would think that the user doesn't care - for example, I could
imagine someone globally enabling it and having pushes become
automatically faster as more and more remotes support it.
[1] https://lore.kernel.org/git/xmqqh7fyfrtl.fsf@gitster.g/