`repos` is a CLI tool that helps to manage multiple git repositories.
git clone https://github.com/amadev/repos.git && cd repos && sudo ./install.sh
Add some repositories with `repos add` command.
repos add https://review.opendev.org/openstack/nova
repos add https://review.opendev.org/openstack/cinder
Repository names must be unique. By default the last segment of repository path used as a name, so conflict could happen. To overcome, use the `–name` option.
The following basic operations are available.
repos list
repos pull
Repositories could be organized hierarchically into groups and operations can be issued on a particular group only. The most useful way of using groups is a `search` operation that helps to search on multiples repositories not depending on a path they were cloned.
repos search --group qemu needle -- --ignore tests
The search backend could be changed with a ‘search_command` config option.
A `repos sync` command pulls and pushes repositories to make sure everything is synchronized. As a pure man dropbox alternative, you can mark your repo with `auto-commit` tag like `repos add … –tags auto-commit` and `repos sync` will auto-commit changes in the repository, pull changes from upstream and push resulting set to upstream. Surely this may be applied to a specific group only.
With `–group` and `–parent` options, repositories can be easily organized into a hierarchy.
repos add-group group-1
repos add repo-1 --group group-1
repos add-group group-1.1 --parent group-1
repos add repo-1.1 --group group-1.1
Group names must be unique. Be careful with circular dependencies.
Config by default resided in $HOME/.repos/conf.yaml.
- db: path where `repos` db yaml stored;
- groups: path to group hierarchy symlinks;
- search_command - a template for command, `grep -HRin` by default, but `ag -f –search-files` recommended;
- repos_default_directory - all repositories without `–path` specification will be cloned here;
- log - path to a log file.
- auto-commit - for `repos sync` command it will stage all changes and commit them;
- shallow - quick clone for big repositories pushing is not planned from.
Besides CLI commands, there is a way to edit DB directly. Especially as DB is a simple YAML file.
Just after installation, a DB file can be found in $HOME/.repos/db.yaml. The actual path can be modified via config DB property (See Config options).
Basically, it has two entities:
Group:
- name
- parent
Repo:
- name - the name of a repository
- path - absolute path in FS where a repository resided
- tags - special properties of a repository (see Repository tags)
- group - group name, that must be defined in Group entity
- remotes - a list of git remotes (not available via CLI)
- branches - a list of branches (not available via CLI)
- config - a list of git config keys and values (not available via CLI)
An example of DB can be seen in file:tests/fixtures/db.yaml
`repos gerrit <url>` generates a database file can be used later with `repos` commands to download all gerrit projects hierarchy.
First, let’s create a new config file and export its path as an env variable.
cat << 'EOF' > ~/.repos/mcp-config.yaml
db: $HOME/.repos/mcp-db.yaml
groups: $HOME/.repos/mcp-groups/
search_command: ag -f --search-files
repos_default_directory: $HOME/src/mcp/
EOF
export REPOS_CONFIG=~/.repos/mcp-config.yaml
Then download gerrit project and convert them into a `repos` DB format. As Gerrit may require authentication an additional http headers could be provided.
repos gerrit \
https://gerrit.mcp.mirantis.com/ \
ssh://avolkov@gerrit.mcp.mirantis.com:29418/ --headers "$HEADERS" \
> $HOME/.repos/mcp-db.yaml
And last step is to make pull.
repos pull