Allow HGRCPATH from environment to propagate to mercurial

[jedbrown]

If the user sets HGRCPATH, it is likely because they want to affect the environment used to make commits (relevant when translating git lightweight tags to mercurial tags) or because they would like to add an extension such as keyring or schemes to the environment.

We are not aware of Mercurial extensions that would negatively affect the behavior of the interfaces that Gitifyhg uses.

This reverts part of 468a4fe8c46f7fb6f571e1902b91b1ce66b831ea

[felipec]

Funny, I recall sending a patch for this, and discussing it in the mailing list. This commit message makes it look as if this idea popped on your head out of nowhere.

[jedbrown]

@felipec You sent a patch for something else (in the test suite) and said you were not interested in submitting a patch for this. Gitifyhg doesn't have a convention of using tags to name everyone that discussed a topic (as with most projects that prefer to discuss commits in pull requests [1]). You're welcome to send another version of this patch.

[1] FWIW, I think mailing lists are better than PRs, but only when everyone uses decent mailers and is disciplined about structuring commits. I work on projects that work both ways. Gitifyhg is not my project, but I adopt its conventions when playing here.

[felipec]

I would have done `git commit --author="Sandor Bodo-Merle [email protected]"', or at the very least "Original patch by". But whatever, it's not like gitifyhg has any standards at all. The original author of the whole code is not even mentioned.

[jedbrown]

@felipec Maybe it would help to look at the commit itself rather than the PR summary:

https://github.com/jedbrown/gitifyhg/commit/aa189f4a31b22a94eabc1ea9c6f0e2296122ee0c

[felipec]

Ahh, I didn't notice. All right.

[felipec]

Wait, this is for gitifyhg.py.