Add credential helpers for Gmail, Outlook and Yahoo

[AdityaGarg8]

Changes

This PR adds links of OAuth2.0 based credential helpers for Gmail, Yahoo and Outlook

Context

OAuth2.0 is a new and more secure way of authentication which many popular email providers are preferring over traditional app based passwords. Support for OAuth2.0 on git send email has been achieved and a documentation to use the same is also available here: git/git@6eb746c

So, adding credential helpers for some popular email providers.

[dscho]

Hmm. I assumed that the credential helpers listed in that section were intended to help Git interact with remote hosts when cloning, fetching and pushing. Not when sending emails, which many Git users (myself included) despise for exchanging source code because it is so fragile and lossy.

This view seems to be confirmed by https://git-scm.com/docs/gitcredentials which does not even talk about emails.

@hickford you added this section, what is your take?

[AdityaGarg8]

In that case maybe https://git-scm.com/docs/gitcredentials needs another section about emails?

[AdityaGarg8]

Although, I find that page quite general, and not limited to cloning and pushing repos.

Git will sometimes need credentials from the user in order to perform operations; for example, it may need to ask for a username and password in order to access a remote repository over HTTP. Some remotes accept a personal access token or OAuth access token as a password. This manual describes the mechanisms Git uses to request these credentials, as well as some features to avoid inputting these credentials repeatedly.

[AdityaGarg8]

I think it should go to "Host specific"? Although will wait for @hickford

[dscho]

@AdityaGarg8 it is obvious that you care a lot about these email helpers, but do realize that I do not.

In fact, it is a constant annoyance that the Git project itself does not use Git to manage its code contributions, i.e. there are only the gitk and git-gui pull requests, and the rest is performed via a medium that is very ill equipped for code review, collaboration on code, lends no support for basic functionality to answer questions like "has this been merged?", and has poor, very poor tools (if any) to control for spam.

I hope that this explains why I am pretty uninterested in manifesting the email-based work "flow" even further by advertising it more than necessary on git-scm.com. The rest of the world has settled on proper code development platforms using merge/pull requests, and that's a good thing.

[AdityaGarg8]

But some projects like linux kernel are still stuck in the email era, and git send-email has been very, very useful for the same.

Also, email helpers got merged in gitcredentials in git/git@6eb746c#diff-1ef172f00a8dcfc263212d304b3c80a1dc5dcef77ae51c25a9ce12ac75ad81c2

So, IMO:

1. We can make a separate section about email helpers in this page and gitcredentials.
2. Or I'll send a patch to revert that commit (which btw will need git send-email as well xD) , and keep the link of the helpers restricted in docs for send-email