For tagged commits produces the output:
- `1.0.1`

For untagged commits with a dirty tree produces the output:
- `1.0.1-19-g23efbc5-dirty`

Performance:
```
git describe --tags --dirty 2> /dev/null
0.07s user 0.01s system 96% cpu 0.086 total
```

This means we can tag any commit without needing to manually remember
to bump the revision every time.

Move the `LinkedKegs` migration into `utils.rb` so it can also be called
from `brew.rb` on startup.

Print a better exception message and handle this in more cases rather
than producing confusing errors when it’s unset.

We'll keep the Homebrew installer pointing to Tigerbrew for now but as
Homebrew/brew technically has no reason to not work on 10.5 let's remove
this check.

Closes #577.

Signed-off-by: Baptiste Fontaine <b@ptistefontaine.fr>

Move some stuff formerly in `Library/ENV` around:
- Move `Library/ENV/$XCODE_VERSION` to `Library/Homebrew/env/super` as they are
  all superenv wrappers and all symlinks to the same version. We never needed
  the "separate shims for separate versions" functionality and it just adds
  confusion.
- Move `Library/ENV/pkgconfig` to `Library/Homebrew/env/pkgconfig` to get more
  things under `Library/Homebrew`
- Move `Library/ENV/scm` to `Library/scm` as these wrappers are not actually
  used by or related to superenv (or stdenv) in any way.

This reverts commit dba1958b.

This reverts commit 252c701c.

Taps installed prior to running the test suite are not visible to the
test suite as most Homebrew paths are redefined as to not mess up the
local installation.

All of these taps use Homebrew internal APIs (or will shortly) and we
autoinstall them all from `brew $CMD`. We should adjust our CI to ensure
that we never accidentally break these taps when making changes to core
code so that these taps can rely more on this core code rather than
having to e.g. vendor equivalent code that never changes on our end.

If the environment variable HOMEBREW_TEST_GENERIC_OS is set ensure that
neither Mac nor Linux-specific code is loaded. This allows easier
testing of cross-platform code on OS X and will make it easier to port
Homebrew to platforms other than OS X and Linux.

Global namespaces are good to avoid when possible.

This version is never wanted at this point and it will help Homebrew
Cask deal with the annoying errors that result from having this version
still around (some which I've already help users debug).

Use the `reason` attribute to be able to handle `UsageError` subclasses
more uniformly and simplify logic in `brew.rb` to handle them together.

Instead of always printing the generic help text, print command-specific
help if it is available and a command raised the `UsageError` exception.
Put the error message underneath the help text (was above) to avoid that
it scrolls off the screen.

Thereby fix a regression where handling the invalid usage would fail to
access `ARGV.usage` removed in c6536066.

Turns out making `empty_argv` a boolean argument for `Homebrew.help` was
not the best idea and having command-to-path mapping and help extraction
in a single method is not flexible enough.

Also only complain about missing help text when `HOMEBREW_DEVELOPER=1`
and otherwise just print the generic help text.

Library/brew.rb:108: warning: `*' interpreted as argument prefix

Showing help makes sense for `brew help <command>`, but showing it for
`brew <command> help` is undesirable and prevents all commands from
accepting a named argument `help` (formula, tap, file name, etc.).

All other help flags are still detected before *and* after the command.

Closes #103.

Signed-off-by: Martin Afanasjew <martin@afanasjew.de>

Keep the footprint of `brew.rb` small. Handle fetching/displaying an
appropriate help text (taking into account various external conditions)
in the `help` command.

Don't exit with a non-zero status code just because an internal command
happens to be undocumented. Also print the generic help in these cases
to provide some help (including a reference to the man page).

This is also used by `brew <cmd> --help`. The basic idea is to have the
documentation as a top level comment in each command file. To find these
comments, they have to be like this `#:`.

This is also used by the `brew man` command to keep the documentation
DRY, and for that there are now a header and footer for the man page.

`Library/ENV` like `Library/Homebrew` is part of Homebrew basecode. It
should be able to be accessed during the `brew tests`.

By adding HOMEBREW_ENV_PATH variable, we allow test suit to locate these
codes.

This means that internal command aliases can be used for Bash commands
(such as the new, Bash-based `brew update`).

Fixes Homebrew/homebrew#49182.

Closes Homebrew/homebrew#49184.

Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>

Because `brew.rb` should never be invoked directly, remove executable
bit and shebang to make that more obvious.

Closes Homebrew/homebrew#48816.

Signed-off-by: Martin Afanasjew <martin@afanasjew.de>

Currently HOMEBREW_BREW_FILE is a String, while other of HOMEBREW_*
variables are all Pathname. This commit unifies them all as Pathname,
so it will not cause any confusion.

Closes Homebrew/homebrew#48872.

Signed-off-by: Xu Cheng <xucheng@me.com>

Closes Homebrew/homebrew#48634.
Closes Homebrew/homebrew#48681.

Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>

Not sure why this is happening (beyond the Chef cookbook stupidly
deciding to not call through `bin/brew`) but fail and print a scary
looking error to hope to point people in the right direction.

Closes Homebrew/homebrew#48261.

Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>

`bin/brew` already sets up a bunch of environment variables. There's no
need to re-export them for external commands. (`HOMEBREW_LIBRARY_PATH`
and `HOMEBREW_CACHE` continue to be determined later in the Ruby code.)

Generated by `brew style --fix Library/brew.rb`

This is now handled by `bin/brew`