For stderr, either attach it to parent stderr or silence it completely.
This enables GIT_TRACE.

After upgrading to Git 2.20.0, all operations that relied on `hub alias`
would indefinitely hang. It can be reproduced using the following:

1. Create a new alias such as `st` for `git status`.
2. Run `hub <alias>` in a git repository.

  ```
  $ hub st

  ... hangs forever
  ```

Inspecting the running process shows that it is executing `git help -a`
and not able to proceed. Digging into the `hub` shows that the `help`
command is called within `IsBuiltInGitCommand`. Once this entrypoint was
found, I started bisecting and found this works in 2.19.x but fails in
2.20.x. Sure enough, the Git 2.20.0 release notes mention a
corresponding change[1].

>  * "git help -a" now gives verbose output (same as "git help -av").
>    Those who want the old output may say "git help --no-verbose -a".

It was even nice enough to include the backwards compatibility fix :)

To fix the hanging, I've restored the existing behaviour by including
the `--no-verbose` flag that mimics the 2.19.x behaviour.

Fixes #1963

[1]: https://github.com/git/git/blob/master/Documentation/RelNotes/2.20.0.txt#L17-L18

Fixes #1379

https://github.com/git/git/blob/117ddefdb4dfd9b40ae60967a7327754d8ce7a87/builtin/commit.c#L633

Before, the code outside of `editor.go` was responsible for prefixing
lines of the commented section with the comment char. The code to do
this was scattered all over the codebase and was difficult to refactor
re: adding support for `commentchar=auto`.

Now, Editor has a `AddCommentedSection()` method that allows for
declarative adding of a commented section. Furthermore, the caller
doesn't have to query git to determine the comment char.

Fixes https://github.com/github/hub/issues/1423

`git rev-parse --show-toplevel` returns an empty string with success
status when inside a bare git repo.

This avoids the go crash and also tweaks `hub issue` and `hub
pull-request` to work even if current working directory name couldn't be
obtained because it's only used for looking up issue/PR templates, which
isn't critical functionality.

Fixes https://github.com/github/hub/issues/1331

This removes an extra step from the process of publishing a pull
request. It also gives the user a chance to back out of the entire
process by saving an empty pull request message.

Ported from my bash version over at
https://github.com/mislav/dotfiles/blob/370154a5adc482afd89606c126bcd18df2560013/bin/git-sync

The old `args.After("echo", ...)` approach won't cut it on Windows since
there is no `echo` executable. Thus, nothing was printed on Windows.

Instead, expand Args type with extra functionality that allows Go
callbacks after all commands in the chain have been run.

Also, the new `args.NoForward()` is now preferred to `os.Exit()` since
it's more descriptive and allows `defer` in the calling function.

Fixes #1254

This matches git behavior. Fixes #835

We only ever read the first hostname from the list because we didn't use
`git config --get-all`.

Fixes #1188

The `create` and `remote` commands needs to infer the current project
name from the project's directory. Instead of using the current working
directory, which doesn't necessarily match the project's toplevel
directory, use `git rev-parse --show-toplevel` which also respects the
`-C` global flag setting.

Fixes #1105, closes #1114

In `hub clone NAME`, "NAME" was previously considered a local resource
if a directory of the same name existed, and the clone command was left
unchanged.

That worked for a while, but some users were surprised that they
couldn't clone their repo named "NAME", only to discover that there was
an unrelated directory "NAME" in the current working directory.

Also, a git bundle is a valid cloneable resource, but is a file and not
a directory.

This refines the detection of cloneable resources. "NAME" is considered
to be locally cloneable if one of the following is true:

- "NAME/.git" exists
- "NAME" is a bare git repo
- "NAME" is a file whose first line includes "git bundle"

It's invoked often from different methods, but always has the same
results. Cache it after the 1st run so subsequent runs are no-ops.

Before:

    HUB_VERBOSE=1 git browse
    $ git config alias.browse
    $ git rev-parse -q --git-dir
    $ git rev-parse -q --git-dir
    $ git remote -v
    $ git rev-parse -q --git-dir
    $ git config hub.host
    $ git rev-parse -q --git-dir
    $ git config push.default
    $ git rev-parse -q --git-path refs/remotes/origin/no-angular
    $ git rev-parse -q --git-dir
    $ git rev-parse -q --git-dir
    $ git rev-parse -q --git-dir

After (6 fewer invocations):

    HUB_VERBOSE=1 git browse
    $ git config alias.browse
    $ git rev-parse -q --git-dir
    $ git remote -v
    $ git config hub.host
    $ git config push.default
    $ git rev-parse -q --git-path refs/remotes/origin/no-angular

[ci skip]

From git documentation:

    -C <path> : Run as if git was started in <path> instead of the
                current working directory. When multiple -C options are
                given, each subsequent non-absolute -C <path> is
                interpreted relative to the preceding -C <path>.

We correctly forwarded the `-C <path>` values as git global flags to git
invocations such as `git rev-parse --git-dir`, but that command is
designed to return the result as a relative path to the value computed
from `-C`. This adds an extra step to transform this relative path to an
absolute one by applying values of `-C` as the base directory.

We can't use `--git-path` on git versions older than 2.5. Those versions
will simply echo `--git-path` as the first line of the output. Instead
of stat'ing that as a file, skip this case and proceed immediately to
fallback for other git versions.

Git 1.5.0 introduces support for worktrees. A worktree has a
.git file, rather than a folder. (The file contents points to to a
.git folder buried underneath the .git folder of the main repository.)

A new option has been added to resolve paths within the git dir,
`git rev-parse --git-path foo/bar`.

The commit uses this new facility, but falls back to the old approach
for backwards compability.

Fixes #969

This fixes #858

Parse more global flags from by following https://github.com/github/hub/blob/1.12-stable/lib/hub/commands.rb#L961-L995

We now have `Cmd.Spawn` and `Cmd.Exec`, to avoid confusion, we use `Cmd.CombinedOutput` for combined output.

This is to avoid the interrupt/pagination issues like https://github.com/github/hub/issues/708. Note that `exec(3)` is not available on Windows: http://golang.org/src/pkg/syscall/exec_windows.go#L339. A fall to `spawn(3)` is used in this case.

This is to `spawn` a process not to `exec` one

It's possible that comments are multiple lines