On Mon, 23 Oct 2017 15:51:06 -0700
Brandon Williams <bmwill@xxxxxxxxxx> wrote:
> On 10/23, Jonathan Nieder wrote:
> > Separately from how to document it, what do you think a good behavior
> > would be? Should the "auto" configuration trigger command line based
> > detection just like no configuration at all? Should the "auto" value
> > for configuration be removed and that behavior restricted to the
> > no-configuration case?
> >
> > I'm tempted to go with the former, which would look like the following.
> > What do you think?
>
> As a user having some variant as 'auto' doesn't make much sense, i mean
> isn't that exactly what the default behavior is?
So you're suggesting the second option ("that behavior restricted to the
no-configuration case")?
I'm leaning towards supporting "auto", actually. At the very least, it
gives the user a clear way to override an existing config.
> Check if my ssh
> command matches existing variants and go with that. What you are
> proposing is the make the existing auto detection better (yay!) though I
> don't know if it warrants adding a new variant all together.
>
> Instead it may be better to stick this new improved detection at the end
> of the existing variant discovery function 'determine_ssh_variant()' as
> a last ditch effort to figure out the variant. That way we don't have
> an extra variant type that can be configured and eliminates some of the
> additional code in the switch statements to handle that enum value
> (though that isn't really that big of a deal).
This sounds like what is already being done in the code.
> > If this looks good, I can reroll in a moment.
Yes, this looks good.
