Thanks for the test!

I think I need a second opinion on the new behaviour. Thing is, when you parse a refspec "refs/heads/master:" with git_refspec_parse, you get a src of "refs/heads/master" and dst is NULL. But when you now transform such a refspec, you do not get NULL but instead you'd get an empty string (or rather a buffer containing an emtpy string). I can't help but feel that this is being inconsistent. The problem is obviously that you cannot return a NULL pointer via the git_buf out parameter.

Going a bit deeper: what would a caller of git_refspec_transform actually expect? He wants to transfor a source ref (potentially with globs) to a destination ref. But in case of "refs/heads/master:" there is no destination ref. Should we, instead of passing back an empty string, raise an error?

@ethomson, do you have some thoughts?

Backing up from the question of

what would a caller of git_refspec_transform actually expect?

We have the question of: “What would a caller of git_refspec__parse followed by git_refspec_transform expect?”

In that case, the input string of "refs/heads/master:" has an empty dst, so we would expect to get back an empty string. I read git_refspec__parse, and it appears to deliberately return NULL. Taking it as givens that both

1. git_refspec__parse + git_refspec_transform should round-trip an empty dst
2. git_refspec__parse (is allow to) returns NULL to mean an empty dst

We reach the conclusion that git_refspec_transform should accept NULL.

We could alternately relax (2) and make git_refspec__parse return "" instead of NULL.

Thanks for your reasoning and this change!