Re: [PATCH v2 6/6] imap-send: correctly report "host" when using "tunnel"

Jeff King [off-list ref] writes:

Yes, I agree that the scenario I'm giving is contrary to what the docs
say. But IMHO it is worth preferring what the code does now versus what
the docs say. The current behavior misbehaves if you configure things
badly (accidentally mix and match imap.host and imap.tunnel). Your new
behavior misbehaves if you have two correctly-configure imap stanzas
(both with a host/tunnel combo). Those are both fairly unlikely
scenarios, and the outcomes are similar (we mix up credentials), but:

  1. In general, all things being equal, I'd rather trust the code as
     the status quo. People will complain if you break their working
     setup. They won't if you fix the documentation.

  2. In the current behavior, if it's doing the wrong thing, your next
     step is to fix your configuration (don't mix and match imap.host
     and imap.tunnel). In your proposed behavior, there is no fix. You
     are simply not allowed to use two different imap tunnels with
     credential helpers, because the helpers don't receive enough
     context to distinguish them.

     And that is not even "two imap tunnels in the same config". It is
     really per user. If I have two repositories, each with
     "imap.tunnel" in their local config, they will still invoke the
     same credential helpers, and both will just see host=tunnel. The
     namespace for "host" really is global and should be unique (ideally
     across the Internet, but at the very least among the hosts that the
     user contacts).

All good points.

Yes, there are many config schemes that would avoid this problem. If you
are going to tie the two together, I think it would make sense to use
real subsections based on the host-name, like:

  # hostname is the subsection key; it also becomes a label when
  # necessary
  [imap "example.com"]

  # does not even need to mention a hostname. We'll assume example.com
  # here.
  tunnel = "any-command"

  # assumes example.com as hostname; not needed if you are using a
  # tunnel, of course
  protocol = imaps

But I would not bother going to that work myself. IMHO imap-send is
somewhat of an abomination, and I'd actually be just as happy if it went
away. But what you are doing seems to go totally in the wrong direction
to me (keeping it, but breaking a rare but working use case to the
benefit of a rare but broken misconfiguration).

Yup.