push Base.push! and LibGit2.push! apart

[rfourquet]

I just noticed that #24818 was incomplete while working on another PR: I know little about LibGit2, but its push! seems quite different from Base's. I also noticed 3 other functions for which the same serparation could be done, but I'm not sure, so I ask for feedback about them: count, map, split. LibGit2 may legitimately extend base functions in this case, the only "problem" is that it clutters the documentation at the REPL (not importing this module would solve this problem, but I guess it's not doable).

[KristofferC]

Do you know if moving LibGit2 to stdlib would solve this problem with documentation being lumped up together? I would guess no.

[rfourquet]

Do you know if moving LibGit2 to stdlib would solve this problem with documentation being lumped up together? I would guess no.

I would guess no too.

This change forces to use a bunch of Base.push! from within the LibGit2 module, which is a bit ugly. As I said, I don't know this module, can someone confirm that LibGit2.push! has a different enough meaning than Base.push! to justify this split?

[rfourquet]

Would this be considered as breaking if this is done in 1.x ?

[nalimilan]

Because due to the name conflict all uses of LibGit2.push! would have to be qualified. But if we move LibGit2 to the stdlib, it should be fine (and we could have a deprecation for some time).

[rfourquet]

Thanks! (my question was indeed poorly phrased, I meant to ask if it would be an acceptable breaking change, or if it would be moved to stdlib, to which you answered)

[JeffBezanson]

Let's rebase this and just try to get it in ASAP.

[rfourquet]

Appveyor failure seems to be a timeout (2h job). This is ready to go, if someone wants to have a look?
As said in the OP, count, map and split could be considered for a similar treatment; I can open a PR if there is feed-back in favor.

[StefanKarpinski]

This we certainly should go ahead with.