git_resource: ignore stderr in get_patch_count when calling git rev-list

[hmmr]

When trying to build one of our projects on dockerhub, we saw the automatic build failing with a badarg:

#12 129.8 ===> Uncaught error in rebar_core. Run with DIAGNOSTIC=1 to see stacktrace or consult rebar3.crashdump
#12 129.8 ===> Uncaught error: badarg
#12 129.8 ===> Stack trace to the error location:
#12 129.8 [{erlang,list_to_integer,["warning: refname '3.0.0rc4' is ambiguous.\n0"],[]},
#12 129.8 {rebar_git_resource,get_patch_count,2,

It appears that in a situation after git checkout -b <TAG>, when rebar_git_resource:get_patch_count/2 is called, the cloned repo is in a state where it has a branch and a tag of the same name. This causes git rev-list <TAG>..HEAD to print "warning: refname '' is ambiguous." to stderr, which in turn confuses a list_to_integer at the end of that function and causes a badarg. Redirecting stderr to /dev/null seems to be a sufficient and harmless way to deal with this issue.

[ferd]

Would it make sense to actually detect and surface the warning to the end user so they know the type of ref they chose is ambiguous?

[hmmr]

Amended, now with the git warning forwarded to the user.

[hmmr]

Hold on, there seems to be an issue with the patch. It appears that Warning and PatchLines sometimes get the stderr and stdout lines the wrong way.

[hmmr]

Amended again, on account of string:split/2 idiosyncratic behaviour (not the stderr/stdout nondeterminism as I suspected in my previous comment):

Erlang/OTP 22 [erts-10.7] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [hipe]

Eshell V10.7  (abort with ^G)
1> string:split("aa\nbb\n", "\n").
["aa","bb\n"]
2> string:split("aabb\n", "\n").  
["aabb",[]]
3> 

(note the inconsistency in handling the \n character in one vs two lines) while in python, we have

Python 3.9.9 (main, Nov 26 2021, 16:55:59) 
[GCC 11.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import string
>>> "aa\nbb\n".split("\n")
['aa', 'bb', '']
>>> "aabb\n".split("\n")
['aabb', '']
>>> 

[ferd]

Yeah that's a thing that can be set. https://www.erlang.org/doc/man/string.html#split-2 mentions supporting default arguments with leading, trailing, or all, and it defaults to leading. Specifying all would have made it work the way you thought, but the weird state of backwards compatibility modules we have prevents us from doing it.