Consider that git log command will, with no extra arguments, list all the commits reachable from current HEAD. In large repositories, this is an expensive operation.

We could potentially limit the output by adding -1, but we could also explore options to use a lower-level approach than git log.

I would suggest that we avoid ever matching text in error messages. I have two main reasons:

1. Forward-compatibility: future git versions might decide to tweak an error message;
2. Localization-sensitivity: not everybody has git in English.

$ LANG=es git rev-list -1 HEAD
fatal: argumento ambiguo 'HEAD': revisi'on desconocida o ruta fuera del 'arbol de trabajo.
Use '--' para separar las rutas de las revisiones, de esta manera:
'git <comando> [<revisi'on>...] -- [<archivo>...]'

If we wanted to detect whether the current branch has any commits, I think we could do git rev-list -1 HEAD, silence stderr, and see if there is a line on stdout.

So this leaves a problem on detecting the branch name when we're on a branch that has no commits yet. We have several options:

1. git branch --show-current: works, but not present in the oldest git version we support (1.9);
2. Scanning the branch name from git log error message: brittle;
3. Parsing the branch name from .git/HEAD file manually: possible, but not straightforward to pull off since .git can be a regular file in case of git worktrees;
4. Avoiding reading the current branch name and just failing with git: not on any branch, basically equating the no-commits scenario with detached HEAD scenario;
5. git symbolic-ref --short HEAD : might do the job, but we'd have to check how far back it is supported, otherwise this is in the same basket as (1).

I'm leaning to (3) as the most "correct" approach, (5) as something to look into, and (4) as a lazy approach.

All very fair criticisms; I knew it was a bad solution but figured you'd have a good suggestion on a different approach ^_^() I just don't have enough lower level git knowledge yet.

git symbolic-ref exists as far back as git 1.9 and I like using it more than the other options. I was going to suggest we switch to that by default instead of the existing rev-parse invocation but it errors on detached HEAD :(

I'll clean up CurrentBranch to use both, I guess.

🔥🔥🔥

This approach looks like it might cover all the cases, but I wonder if we could get away with using just a single invocation without fallbacks? It looks like git symbolic-ref --quiet --short HEAD could be just what we need:

• exit code == 0 + lines on stdout: the branch name was determined successfully
• exit code != 0 + no stderr: detached HEAD (no current branch)
• exit code != 0 + lines on stderr: some other error with which we should abort the process

great thought, implemented.

This is going to panic if err is not of type *run.CmdError.

As a rule of thumb, we should never assume that an error is guaranteed to be of any specific type, but always check the type:

var cmdErr *run.CmdError
if errors.As(err, &cmdErr) {
	cmdErr.Stderr.Len()
}

hm; I opted for the panic because it seemed like err was always supposed to be a *run.CmdError and panicking would signal to a developer that they were changing that contract. If we silently ignore the failed cast, doesn't that mean we can let a bug go unacknowledged?

ah, re-reading more closely i see it's possible to not get a CmdError out of a prepared command. I'll fix the type assertion.

Should this be of type error so we can return any error type that we want, instead of just *run.CmdError?

like i said above I misread the code as always using CmdError and didn't see the need for that flexibility; i'll update it.