| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test suite uses cram to run integration tests through `/bin/sh`.
The tests are all high-level acceptance tests; they should work
regardless of the implemention code.
To run them, you must first install cram:
sudo pip install cram
Then the `check` target will run them:
make check
Failure output should be printed clearly to stdout, but in general: full
test output is in `test/test-suite.log` and output specific to a test
named `foo.t` is in `foo.t.log`.
Tests are now encouraged in `CONTRIBUTING.md` as part of the normal pull
request process.
This is a TAP-enabled test suite.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Under Solaris, use ksh instead of `/bin/sh`.
This uses `$SHELL` as a POSIX shell, coupled with a `configure` check
that sets it correctly.
Note that the POSIX shell might end up being bash, so this actually
introduces more fragmentation than it reduces.
Taken from https://github.com/freedreno/mesa/blob/master/configure.ac
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of requiring contributors to update rcm(7), pull the list of
contributors from the git log instead.
The `rcm.7` file has been moved to `rcm.7.mustache`. The `autogen.sh`
command will write `rcm.7` using autocontrib, a quick script included in
this commit.
This commit adds a `.mailmap` file, used by git-shortlog(1) to produce
correct and useful names and email addresses. An initial `.mailmap` has
been added to correct some existing email addresses and duplications.
`.mailmap` is documented in [Documentation/mailmap.txt][mailmap] for
git.
This adds a maintainer dependency on Ruby and the mustache gem. The
autocontrib program is spiked out in Ruby due to my familarity with the
language, but the choice of templating language (mustache) allows
flexibility for switching languages later. This is a dependency
requirement only for people who run `autogen.sh` -- maintainers.
This adds a maintainer dependency on git. Again, this is only for
maintainers, and many (all?) of them need git to get rcm's source
anyway.
Thanks to Patrick Brisbin and George Brocklehurst for the review.
[mailmap]: https://github.com/git/git/blob/6a907786af835ac15962be53f1492f23e044f479/Documentation/mailmap.txt
|
| |
|
|
|
|
|
|
|
|
|
| |
It introduces the `Makefile.am` from gitsh, and abstracts it a bit. This
`Makefile.am`, or most of it, could be dropped into gitsh again. How to
use it is documented in `DEVELOPERS.md`.
The whole release process is more consistent and simple: `make release`
to build a tarball, Homebrew, Arch, Debian, HTML (from manpages), and
tag it, pushed to the various repos, and with cleanup. The `release`
target is composed of smaller targets that stack well.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
The `make release` command will build the Debian package, push the
version to a git tag on GitHub, and upload the docs to GitHub pages.
This also adds a `deb` target, along with `build-docs`, `upload-docs`,
`build-tag`, and `push-tag`.
In addition, introduce a `NEWS.md` file.
Both `rcm.sh.in` and `NEWS.md.in` will act as input files. This is to
abstract over the version number.
|
| |
|
|
|
|
|
|
|
| |
The following command can generate a Debian package:
debuild -us uc
The directory structure and tarball must be perfectly set up first. This
is documented in `DEVELOPERS.md`.
|
|
|
Replace the `Makefile` with a `configure.ac` and a set of `Makefile.am`.
|
patrick brisbin
Mike Burns