got is a script to make it easier to manage all the version controlled
repositories you have on all the computers you use. It can operate on all,
some, or just one repo at a time, to both check the status of the repo (up to
date, pending changes, dirty, etc.) and sync it with any upstream master.
got also supports forking a GitHub repo and adding it to the list of managed repositories.
cd some/proj/in/a/vcs got add # answer prompts for various information # or run with '-D' to take all defaults # show managed repositories got list got ls # show managed repositories sorted by path (default = sort by name) got ls -p # remove repo #1 from the list got remove 1 # remove repo named 'bar' from the list got remove bar # remove all repos tagged 'foo' without confirmation prompts got rm -f -t foo # remove repo #3 without confirmation prompts and be noisy about it got rm -f -v 3 # show status (up-to-date, dirty, etc.) for all repos got status # show status for repo #3 got st 3 # update all repos with configured remotes got update # update repo named 'bar' got up bar # Note: if a repo is in the list but doesn't have a local checkout, 'got # update' will create directories as needed and do the initial check out. # fork a github repo and add it to your list of repos got fork https://github.com/somebodies/repo_name # note: this doesn't actually check out the repo, but running 'got up # repo_name' will work as described above. # also note: the default path to a repo added via 'fork' is a directory # named 'repo_name' in the current working directory # open a subshell with working directory set to 'path' of repo #1 got chdir 1 # fork a subshell with working directory set to 'path' of repo foo got cd foo # show version of got got version
In addition to the subcommand-specific options illustrated in the SYNOPSIS, all the subcommands accept the following options:
--verbose / -v
Be more verbose about what is happening behind the scenes
--quiet / -q
Be more quiet
--tags / -t
Select all repositories that have the given tag. May be given multiple times. Multiple args are (effectively) 'and'-ed together.
--no-color / -C
Suppress colored output
--color-scheme / -c
Specify a color scheme. Defaults to 'dark'. People using light backgrounds may want to specify "-c light".
The name given to the option indicates a library to load. By default this library is assumed to be in the 'App::GitGot::Outputter::' namespace; the given scheme name will be appended to that namespace. You can load something from a different namespace by prefacing a '+'. (E.g., '-C +GitGot::pink' will attempt to load 'GitGot::pink'.)
If the requested module can't be loaded, the command will exit.
See COLOR SCHEMES for details on how to write your own custom color scheme.
- repo name, repo number, range
Commands may be limited to a subset of repositories by giving a combination of
additional arguments, consisting of either repository names, repository
numbers (as reported by the '
list' subcommand), or number ranges (e.g.,
will operate on repository numbers 2, 3, and 4).
Note that if you have a repository whose name is an integer number, bad things are going probably going to happen. Don't do that.
Color scheme libraries should extend
App::GitGot::Outputter and need to
define four required attributes:
color_minor_change. Each attribute should be a
read-only of type 'Str' with a default value that corresponds to a valid
Term::ANSIColor color string.
Seeing Ingy döt Net speak about AYCABTU at PPW2010 was a major factor in the development of this script -- earlier (unreleased) versions did not have any way to limit operations to a subset of managed repositories; they also didn't deal well managing output. After lifting his interface (virtually wholesale) I ended up with something that I thought was worth releasing.
drdrang prodded me about making the color configuration more friendly to those
that weren't dark backrgound terminal people. The colors in
App::GitGot::Outputter::light are based on a couple of patches that drdrang
Currently git is the only supported VCS.