Le 04/08/2017 à 23:22, Jeff King a écrit :
> On Fri, Aug 04, 2017 at 02:18:13PM -0700, Junio C Hamano wrote:
>>> I also think it might be reasonable to scrap all of this ad-hoc imap
>>> code in favor of curl, which already gets these cases right. We already
>>> have a curl-backed implementation. I think we just left the old code out
>>> of conservatism. But it seems somewhat buggy and unmaintained, and I
>>> wonder if we aren't better off to simply encourage people to install
>> That is a very attractive direction to go in, especially in the mid
>> to longer term. Perhaps we declare that the ad-hoc hardcoded imap
>> is deprecated in the next cycle and drop the support by the end of
>> this year?
> That is fine by me. AFAIK, we already build the curl support by default
> when a sufficiently-advanced version of curl is available. So if there
> were feature-parity problems hopefully somebody would have reported it.
> I think the deprecation here can be relatively fast because we're not
> actually dropping support for any feature. We're just requiring that
> they install curl to get the same functionality (which might be
> inconvenient, but it's a heck of a lot less inconvenient than "there's
> no way to do what you want anymore").
There is at least one difference right now:
When using --curl, the username/password are loaded from the gitconfig file
When using the legacy imap interface, it goes through credential_fill which
prompts for a password.
I don't think everyone is ready to store his email account password in a
gitconfig file (I know I'm not).
I don't see why it couldn't be fixed. I'll give it a try tomorrow.
Also it probably make sense to have at least one release where --curl is the
default. Until your mail I had no idea this option existed so I never tried it
Making it the default will make sure almost everyone is using it and that there
But I agree it's probably safer and cleaner to let curl handle everything and
drop the legacy stuff once it fully works.