In commit 08998d6 of PR git-lfs#5779 we
updated our Git credential helper test program to reflect the new
support in Git v2.46.0 for authentication schemes other than those
using usernames and passwords, specifically by accepting input
lines with the "capability[]" key and replying with similar lines
as appropriate.

In particular, if the client sends one or more "capability[]" lines,
we check their values against the list of capabilities our helper
program supports, which at the moment is just the "authtype" and
"state" capabilities.  If any matches are found, we include those
in "capability[]" lines in our reply, excluding any capabilities
the client announced but which our program does not support.

At the moment, we do this by first overwriting the "capability[]"
entry in the map of key/value pairs we created from the client's input,
and then copying that entry into the "return" map of key/value pairs
we'll send back to the client.  Finally, we make sure to output
the values from the "capability[]" entry in that map before sending
the values of all the remaining entries.  (Note that each entry
in these maps may have multiple values.  If a key is multi-valued,
we send each value on a separate line in the output.)

We can simplify our handling of these "capability[]" lines somewhat
by skipping the step where we overwrite the entry in the map of
input lines, and also by skipping the copy of the values we intend
to return into the "result" map.  Instead, we can just return the
filtered set of capabilities we support from our discoverCapabilities()
function, and then output the values from that set first before
sending the values from our "return" map.

This does mean that we only pass the filtered set of capabilities
to the Serialize() method of our "credential" structure, instead of
the full set received from the client.  But this change has no
functional impact because that method only needs to check for
the capability types we support ("authtype" and "state"), so those
will always be in the filtered set of capabilities, assuming the
client sent them to us.

In commit 08998d6 of PR git-lfs#5779 we
updated our Git credential helper test program to reflect the new
support in Git v2.46.0 for authentication schemes other than those
using usernames and passwords, specifically by accepting input
lines with the "capability[]" key and replying with similar lines
as appropriate.

In particular, if the client sends one or more "capability[]" lines,
we check their values against the list of capabilities our helper
program supports, which at the moment is just the "authtype" and
"state" capabilities.  If any matches are found, we include those
in "capability[]" lines in our reply, excluding any capabilities
the client announced but which our program does not support.

At the moment, we do this by first overwriting the "capability[]"
entry in the map of key/value pairs we created from the client's input,
and then copying that entry into the "return" map of key/value pairs
we'll send back to the client.  Finally, we make sure to output
the values from the "capability[]" entry in that map before sending
the values of all the remaining entries.  (Note that each entry
in these maps may have multiple values.  If a key is multi-valued,
we send each value on a separate line in the output.)

We can simplify our handling of these "capability[]" lines somewhat
by skipping the step where we overwrite the entry in the map of
input lines, and also by skipping the copy of the values we intend
to return into the "result" map.  Instead, we can just return the
filtered set of capabilities we support from our discoverCapabilities()
function, and then output the values from that set first before
sending the values from our "return" map.

This does mean that we only pass the filtered set of capabilities
to the Serialize() method of our "credential" structure, instead of
the full set received from the client.  But this change has no
functional impact because that method only needs to check for
the capability types we support ("authtype" and "state"), so those
will always be in the filtered set of capabilities, assuming the
client sent them to us.

In commit 08998d6 of PR git-lfs#5779 we
updated our Git credential helper test program to reflect the new
support in Git v2.46.0 for authentication schemes other than those
using usernames and passwords, specifically by accepting input
lines with the "capability[]" key and replying with similar lines
as appropriate.

In particular, if the client sends one or more "capability[]" lines,
we check their values against the list of capabilities our helper
program supports, which at the moment is just the "authtype" and
"state" capabilities.  If any matches are found, we include those
in "capability[]" lines in our reply, excluding any capabilities
the client announced but which our program does not support.

At the moment, we do this by first overwriting the "capability[]"
entry in the map of key/value pairs we created from the client's input,
and then copying that entry into the "return" map of key/value pairs
we'll send back to the client.  Finally, we make sure to output
the values from the "capability[]" entry in that map before sending
the values of all the remaining entries.  (Note that each entry
in these maps may have multiple values.  If a key is multi-valued,
we send each value on a separate line in the output.)

We can simplify our handling of these "capability[]" lines somewhat
by skipping the step where we overwrite the entry in the map of
input lines, and also by skipping the copy of the values we intend
to return into the "result" map.  Instead, we can just return the
filtered set of capabilities we support from our discoverCapabilities()
function, and then output the values from that set first before
sending the values from our "return" map.

This does mean that we only pass the filtered set of capabilities
to the Serialize() method of our "credential" structure, instead of
the full set received from the client.  But this change has no
functional impact because that method only needs to check for
the capability types we support ("authtype" and "state"), so those
will always be in the filtered set of capabilities, assuming the
client sent them to us.

In commit 08998d6 of PR git-lfs#5779 we
updated our Git credential helper test program to reflect the new
support in Git v2.46.0 for authentication schemes other than those
using usernames and passwords, specifically by accepting input
lines with the "capability[]" key and replying with similar lines
as appropriate.

In particular, if the client sends one or more "capability[]" lines,
we check their values against the list of capabilities our helper
program supports, which at the moment is just the "authtype" and
"state" capabilities.  If any matches are found, we include those
in "capability[]" lines in our reply, excluding any capabilities
the client announced but which our program does not support.

At the moment, we do this by first overwriting the "capability[]"
entry in the map of key/value pairs we created from the client's input,
and then copying that entry into the "return" map of key/value pairs
we will send back to the client.  Finally, we make sure to output
the values from the "capability[]" entry in that map before sending
the values of all the remaining entries.  (Note that each entry
in these maps may have multiple values.  If a key is multi-valued,
we send each value on a separate line in the output.)

We can simplify our handling of these "capability[]" lines somewhat
by skipping the step where we overwrite the entry in the map of
input lines, and also by not making a copy of the values we intend
to return into the "result" map.  Instead, we can just return the
filtered set of capabilities we support from our discoverCapabilities()
function, and then output the values from that set first before
sending the values from our "return" map.

This does mean that we only pass the filtered set of capabilities
to the Serialize() method of our "credential" structure, instead of
the full set received from the client.  But this change has no
functional impact because that method only needs to check for
the capability types we support ("authtype" and "state"), so those
will always be in the filtered set of capabilities, assuming the
client sent them to us.