When using a push.default = current triangular workflow, apart from
using @{push} to determine the remote branch name, we should also follow
the
1. branch.<name>.pushRemote
2. remote.pushDefault
3. branch.<name>.remote
...list to determine which remote Git pushes to.
When using a push.default = current central workflow [1], we should use
@{push} instead to locate the remote branch.
In fact, @{push} covers most cases in push.default = upstream too. The
branch.<name>.merge is probably only needed when using RemoteURL and
different remote / local branch names.
[1] https://github.com/tpope/vim-fugitive/issues/1172#issuecomment-522301607
Theoretically this should be clearer and more robust than the previous
version which had some custom loop logic while trying to parse newlines
and determine whether it had reached a new commit entry by trying to parse
a git sha. This would not have worked correctly if a commit body contained
a sha on a new line.
Since this is guarded by the line starting with a git sha, it must
be a line of the form 'sha,title,body', so there can never be only
two entries since the Split fn will produce an empty string in the
last spot in the case of a missing body.
This is used to fill the body of PR with all commits msg + body
of every commits because there can be lot of useful information.
Signed-off-by: Federico Guerinoni <guerinoni.federico@gmail.com>
Before, git client was not correctly setting `ErrNotOnAnyBranch` error.
Because of that, `gh pr status` was not functioning correctly when run
from the detached HEAD. This commit fixes that.
Fixes#7051
The command was using this to check for git repo context:
git rev-parse --is-inside-work-tree
With this change, this is used instead:
git rev-parse --git-dir
The latter approach works in the context of a bare git repository, which does not have a worktree.
