Jeff King <peff@xxxxxxxx> 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.
