support some convenient warpper functions?

[Roger-luo]

I'm wondering if people are open to have some convenient functions in this package? e.g

function remote_repo_url(repo::String=pwd())
    return cd(repo) do
        readchomp(`$(git()) config --get remote.origin.url`)
    end
end

function remote_exists(repo::String=pwd())
    url = remote_repo_url(repo)
    p = cd(repo) do
        redirect_stdio(stderr=devnull, stdout=devnull) do
            run(ignorestatus(`$(git()) ls-remote --exit-code $url`))
        end
    end
    return p.exitcode == 0
end

function default_branch(repo::String=pwd(); remote::String="origin")
    remote_exists(repo) || error("cannot determine default branch, remote does not exist")

    url = remote_repo_url(repo)
    return cd(repo) do
        s = redirect_stdio(stderr=devnull) do
            readchomp(ignorestatus(`$(git()) ls-remote --symref $url HEAD`))
        end
        m = match(r"'s|^ref: refs/heads/(\S+)\s+HEAD|\1|p'", s)
        m === nothing && error("invalid remote response: $s")
        return m[1]
    end
end

I think it would be nice to have some convenient Julian functions like these in this package so that we can just use them as Git.default_branch etc. instead of searching how to do X then do the interpolations manually.

The reason why I don't like them in a separate package is that I find this package is already wrapping Git_jll and the module name Git is shorter than a separate one such as GitHelper, what do you think?

[ExpandingMan]

This is something I often need but rather amazingly does not seem to exist in Julia.

Would maintainers be receptive to doing that in this package or should it be done in a separate package?

[giordano]

Not sure I count as a maintainer (haven't contributed a single line of code to this package), but it looks a good idea to me. This is light wrapper around git commands, but I think helper functions are always useful.

[DilumAluthge]

Yeah, we are sitting on a very nice namespace here, so we might as well use it.

The one thing I would ask is that we try to keep 100% coverage for all of these convenience functions; that should help prevent them from regressing.

[ExpandingMan]

Hm, I was thinking that tests might be hard but I guess it's always safe to assume we can talk to the repo for the project itself? Then we might have branches or tags purely for testing purposes which is kind of a fun quirk.

Anyway, I might make some contributions as I have already done "quick and dirty" versions of this 2 or 3 times and it would certainly seem worth it to do it for real before I have to do it again.

100% coverage might be tricky but I'll give it a shot if I do make a PR.