Fix handling of tokens (single part credentials) in URLs

[pradyunsg]

Closes #6796

Supersedes and closes #6795

[pradyunsg]

CI driven development! \o/

[cjerdonek]

I would be more specific by mentioning the case of “a username in the URL with no password (e.g. a token)” since that is the case that everyone has been reporting and would want to know is fixed when reading the release notes. Also, if it’s too vague people might think it might also include the quoting issue, which was also reported but we’re not fixing.

[pradyunsg]

Agreed.

[pradyunsg]

Could someone else review this PR? I'm inclined to merge it but I just wanna make sure that no one has any outstanding issues here.

To that end, if no one raises any concerns by Sunday morning IST, I'll merge this (and make a pip 19.2.2 release the next week).

[booleand]

@pradyunsg There are commits which show me as the author, yet I did not make the changes.

This could cause confusion when trying to maintain the code base. For example if someone needed to track down the original author of a commit.

This applies to all of ccac31a and b5b70ad.

It also applies to the commit message of 5036631 which forms part of the commit. The original commit is booleand@d07b7a3

[pradyunsg]

Ah, yes. I rebased off your PR, which is why git credited you as the author.

If you mind, I'm happy to change things up to remove the attribution.

[booleand]

no worries.

Yes, it makes sense to remove the attribution.

[cjerdonek]

To that end, if no one raises any concerns by Sunday morning IST, I'll merge this (and make a pip 19.2.2 release the next week).

@pradyunsg Could you also include the fix for issue #6804 (PR #6827) when you release, which was the other 19.2 regression? (I'm assuming the PR can be merged by then as the fix is trivial.)

Also, since there have been 19.3-specific changes to master since the last release, I'm wondering if the fixes should be cherry-picked prior to release (to minimize the chance of introducing new regressions).

[pradyunsg]

I'm wondering if the fixes should be cherry-picked prior to release (to minimize the chance of introducing new regressions).

Yep yep. I'll be cherry-picking the specific regressions that we want to fix; not releasing off master.

The earlier bugfix releases blocking master or going straight off master, was mostly because I was being lazy. :)

[pradyunsg]

Doing a squash-merge to make cherry-picking easier.