gits(1)

๐Ÿ“ฆ version 2.0.2, in opensuse-leap 16.0

๐Ÿฉท gits(1) ๐Ÿฉท

okay so this is the User Contributed Perl Documentation page for gits(1), and the Gitslave Home Page is Gitslave Home Page: <http://gitslave.sf.net>. bestie, buckle up ๐Ÿ’–


๐ŸŒธ NAME ๐ŸŒธ

gits โ€” the git slave repository tool for multi-repository management. periodt.


โœจ SYNOPSIS โœจ

here's the whole vibe:

gits [-p|--parallel COUNT] [-v|--verbose]+ [--quiet] [--help]
[--version] [-n|--no-pager] [--paginate] [--eval-args] [--exclude
SLAVE-REGEXP] [--keep-going] [--no-commit] [--no-hide] [--no-progress]
[--no-master] [--with-ifpresent|--just-ifpresent] SUBCOMMAND [ARGS]...

๐Ÿ’– OVERVIEW ๐Ÿ’–

okay so gits is a program that helps you assemble a meta-project out of a bunch of individual git repositories. when you're using gits, those repos operate like they're one git repository instead of many โ€” similar to the way that CVS works by default and svn (v1.5) can be coerced to work. some of these individual git repositories may be part of other meta-projects as well. ๐Ÿ’…

ngl, the functionality provided by git-submodule is not sufficient for this mode of operation. most git commands, like checkout or commit, do not recursively descend into the submodules, so you are forced to do execute all git commands N+1 times (leading to pain and mistakes). also, submodules revisions are tracked in the supermodule, so that changes to a submodule made outside the supermodule are not automatically seen. since git does not allow partial checkouts, we are left with little alternative. ๐Ÿ˜ญ

thus, to solve these problems gits was born. complexity pain is still involved, but the hope is that it is minimized compared to all of the other alternatives. โœจ

the basic theory is that there are a few sub-commands (prepare, attach, populate) which help set up the meta-project for gits operations. then, except for git commands with specific filenames, like git add FILENAME; git reset FILENAME; etc., you should use gits instead of git, and the command will run on all repositories in the project. ๐Ÿซถ

๐ŸŒˆ Example Usage ๐ŸŒˆ

in the following example, we will have the following master repositories:

  ssh://sourcemaster/src/repos/super.git
  ssh://sourcemaster/src/repos/lib1.git
  ssh://sourcemaster/src/repos/lib2.git

the desired working layout of directories with .git in them on disk is:

  ..../super
  ..../super/lib1
  ..../super/lib2

๐Ÿ›’ Clone a gits project ๐Ÿ›’

gits clone [--[no-]fromcheckout] [--nohooks]
[--reference[checkout]=PATH] SUPERPROJECT-URL

this command clones an existing superproject and all associated slave repositories. it runs git clone on the arguments you provide (allowing you to change the name of the checked-out repository for example) and then runs gits populate inside that newly checked out repository. if you are cloning from an existing gitslave checkout instead of the master layout (the master layout is specified in the gits attach commands), you would want to use the --fromcheckout argument. ๐ŸŽ€

by default, if there is a git-hooks directory present in the superproject, hooks there will be symlinked into the .git/hooks directory in all related repositories. adding --nohooks will disable this management. ๐Ÿช

  --------------------------------------------------
  gits clone ssh://sourcemaster/src/repos/super.git super2
  cd super2
  --------------------------------------------------

the gits option --with-ifpresent can be used with this command to populate all conditional slave repositories (those marked with ifpresent flag). ๐Ÿ’–

the clone options --reference=PATH or --referencecheckout=PATH work like the git clone --reference option, modifying the path based on the normal rules (the --fromcheckout rules are used with --referencecheckout) for upstream repository construction. you must use equals (=) to separate the PATH argument from the option, you cannot use whitespace as allowed by git. โš ๏ธ

๐Ÿ’€ the purpose of the --reference options is to avoid lengthy network copies if you already have a local repository. note that the use of shared repositories created by --reference is potentially dangerous; see the notes on --shared in the git-clone man page and consider running gits repack -a to remove these linkages.

๐ŸŒฑ Initialize a gits project ๐ŸŒฑ

gits prepare

you run this command in the git directory which will be your top level master repository (super here). typically you would clone this top level master from some other location which has all of your git projects. ๐Ÿซถ

  --------------------------------------------------
  git clone ssh://sourcemaster/src/repos/super.git super
  cd super
  gits prepare
  --------------------------------------------------

๐Ÿงฒ Add a slave repository to top level master ๐Ÿงฒ

gits attach [--recursive=FILENAME] [--reference=PATH] [--adminonly] REPOSITORY LOCALPATH [FLAGS]

clone the named git repository into the named local directory, and set it up for further gits operations. ๐Ÿ› ๏ธ

typically LOCALPATH would be a path relative to the top level working directory, for example, a subdirectory in the top level. ๐Ÿ“

REPOSITORY can also be relative (relative to the URL the top level master checkout was cloned from). it may also be an absolute URL but if so, gits remote add is not going to be happy. if the URL starts with ^, it will use only the method and hostname from the master's URL. otherwise, it will be relative to the fully qualified path. we will show both in operation in the example. ๐Ÿ‘€

the only [flags] currently supported is "ifpresent" which will be set for this slave repository. other people cloning or populating the superproject will not check out this subrepository if this flag is set, unless they add --with-ifpresent or otherwise arrange for the LOCALPATH to be created. ๐Ÿซถ

if the --recursive=FILENAME argument is present (and you must use the --recursive=FILENAME style, not "--recursive FILENAME") the repository you are attaching will be treated as a recursive gitslave master underneath the top-level gitslave master. the filename will typically be ".gitslave". it is relative to the localpath you checked out and must not have any / in it. ๐ŸŒ€

the attach option --reference=PATH works exactly like the git clone --reference option. in fact this option will be passed as-is to the git clone command. you must use equals (=) to separate the PATH argument from the option, you cannot use whitespace as allowed by git. โš ๏ธ

๐Ÿ’€ the purpose of the --reference option is to avoid lengthy network copies if you already have a local repository. note that the use of shared repositories created by --reference is potentially dangerous; see the notes on --shared in the git-clone man page and consider running gits repack -a to remove these linkages.

if the --adminonly option is given, this tells gitslave to set up the management files and to NOT clone. you must clone through a subsequent prepare or some manual action. ๐Ÿ˜ณ

  --------------------------------------------------
  gits attach ../lib1.git lib1
  gits attach ^/src/repos/lib2.git lib2
  gits attach --recursive=.gitslave ../../super2 supersub
  gits push
  --------------------------------------------------

the push in the example is to share the attach with other users. ๐Ÿ“ค

๐Ÿ“ฆ Checkout any slave repositories that may have been added ๐Ÿ“ฆ

gits populate [--[no-]fromcheckout] [--nohooks] [--reference[checkout]=PATH] [SLAVES]...

go through the list of configured slaves and check out (clone) any which have not already been retrieved. ๐Ÿงš

with --fromcheckout, assume that the remote repository is a gits checkout instead of in standard repository layout. with --no-fromcheckout, assume that the remote repository has the standard layout. if either option is given, sets the default repository layout, which is used when no explicit option is provided. ๐Ÿง 

the gits option --with-ifpresent can be used with this command to populate all conditional slave repositories (those marked with ifpresent flag). you can also populate particular conditional slave repositories by listing them on the command line. ๐Ÿ’–

by default, if there is a git-hooks directory present in the superproject, hooks there will be symlinked into the .git/hooks directory in all related repositories. adding --nohooks will disable this management. ๐Ÿช

the populate options --reference=PATH or --referencecheckout=PATH work like the git clone --reference option, modifying the path based on the normal rules (the --fromcheckout rules are used with --referencecheckout) for upstream repository construction. you must use equals (=) to separate the PATH argument from the option, you cannot use whitespace as allowed by git. โš ๏ธ

๐Ÿ’€ the purpose of the --reference options is to avoid lengthy network copies if you already have a local repository. note that the use of shared repositories created by --reference is potentially dangerous; see the notes on --shared in the git-clone man page and consider running gits repack -a to remove these linkages.
  --------------------------------------------------
  gits populate
  --------------------------------------------------

๐Ÿงน Safely delete local repositories that are no longer wanted ๐Ÿงน

gits release [-n] --all | --just-ifpresent | SUPERPROJECT | SLAVES...

go through the list of configured slaves (or slave arguments) and confirm that there are no unresolved conflicts, untracked (and not ignored) files, uncommitted changes (including staged or stashed changes), unpushed commits, or unmerged private branches, and that there is a tracking branch in each repository. if these conditions are met in all of the selected slaves, the selected slave directories are removed (rm -rf). ๐Ÿ˜ณ

the --no-commit (or -n) option prevents repositories from being removed. (note that if -n is passed to 'gits' instead of the 'release' subcommand, it also disables automatic pagination as --no-pager). this option is implied if the superproject is the root directory (/) or if paths to any slave repositories start with dot (.), contain .. (parent directory) components, or are absolute (start with /). ๐Ÿ›‘

the --just-ifpresent option can be used to release only conditional slave repositories (marked with ifpresent flag). this option cannot be used with slave repository arguments or --all. ๐Ÿ’…

the --all option releases the entire current superproject; unless -n, --no-commit, or --no-master is used, the current directory is removed, breaking relative paths until you change directory. instead, you can pass one superproject as an argument with an absolute path (starting with /); this will work from any directory. ๐Ÿ’€

other arguments are treated as the names of slave repositories to release. only one recursive superproject can be specified, and only as an absolute path. slave arguments cannot start with dot (.) or contain certain shell metacharacters (semicolon, newline, or quotes). slave arguments cannot be combined with --all or --just-ifpresent options. โš ๏ธ

The --force option can force removal even if some repositories aren't in the state we noted above. This is EXTREMELY DANGEROUS and roughly equivalent to rm -rf on the arguments โ€” for this reason, --force cannot be combined with --all or a superproject argument. ๐Ÿ’€

gits release --just-ifpresent
gits release lib1
gits release -n --all
gits release /path/to/super2

๐Ÿ’… Remove a slave repository from top level master

gits detach [--force] SLAVE

This does a gits release on SLAVE. If that succeeds, it removes the slave repository from the local filesystem and removes the slave from .gitignore and the .gitslave management file, so it won't be used in later gits activities. โœจ

The --force option overrides the gits release check. If you do that, the repository is not removed โ€” only .gitignore and .gitslave are affected. ๐Ÿ™ˆ

The --no-commit option only removes the slave from .gitignore and .gitslave; those changes are not committed, and the slave repository is not removed from the local filesystem.

gits detach lib1
gits push

The push in the example is to share the detach with other users. ๐Ÿซถ


๐ŸŒ€ Perform a pull operation for all tracked branches

gits pulls [pull args]

For each branch being tracked by the superproject, it goes through the list of configured slaves, checks you out to the branch, performs a pull, then switches back to the branch you were on.

Please see SUBSTITUTION for info on how to replace part of the command with the slave repository name for each executed command.

In the common case where no repository or refspec is provided as an argument, pulls performs a fetch once (in the current branch of each slave) and then rebases (with --preserve-merges) or merges in each branch. This reduces redundant network overhead in the common case where all branches of a repository have the same remote, but if that's not the case, only the current remote will be fetched. If you want to force the slower operation of a pull in each branch, pass the -- argument, e.g. gits pulls --rebase --. ๐ŸŒˆ

gits pulls --rebase

๐ŸŒธ Perform a pull operation for the current branch only

gits pull [pull args]

Go through the list of configured slaves and perform a pull. Note that even though only the current branch HEAD will be advanced, the commits on other branches will still be fetched. ๐Ÿ‘‘

Please see SUBSTITUTION for info on how to replace part of the command with the slave repository name for each executed command.

gits pull --rebase
gits pull otherhost:/src/work/wb/%%dir%%

๐ŸŽ€ Show unified commit logs in a fixed output format

gits logs [log args]

For each branch being tracked by the superproject, generate a list of the "log" messages as specified by the log args, and output them in a fixed format, with related commits grouped together and ordered by time.

Do not provide git log options that modify the output format โ€” they will break the ordering and grouping functionality. Only arguments that control the selection of commits should be used. (Using the --date={relative,local,default,iso,rfc,short} option is okay, and will modify the displayed date format.)

The related commit grouping groups together all commits (in any sub-project) within an 8-hour period that have the same author e-mail and commit message. ๐Ÿ•—

gits logs HEAD...Product-3.1.1

๐Ÿฆ‹ Perform an arbitrary command for all tracked branches

gits exec COMMAND [ARGS]

For each slave being tracked by the superproject and the superproject itself, cd to the slave directory and execute the listed command.

Please see SUBSTITUTION for info on how to replace part of the command with the slave repository name for each executed command.

gits exec gitk
gits exec git diff

gits resolve [--[no-]fromcheckout] REPOSITORY LOCAL_RELPATH [REMOTE]

This goes through the same process that gits uses for resolving relative repository URLs into absolute URLs, for debugging and certain porting efforts. You may specify the remote of the superproject you wish the relative repository to be in relation to: by default it uses origin.

With --fromcheckout, resolve URLs as if the repository were a clone of another gits checkout. With --no-fromcheckout, resolve URLs as if it were not a clone of another gits checkout. By default it uses the saved repository layout from gits populate or update-remote-url; however gits resolve does not change the saved default even if --fromcheckout or --no-fromcheckout is given. ๐Ÿงš

gits resolve ../otherpos otherpos
gits resolve ../otherpos otherpos otherremote

๐Ÿ”ฅ Update the URL a remote repository points at

gits update-remote-url [--[no-]fromcheckout] REMOTENAME NEWURL

Update the superproject's remote.REMOTENAME.url to be NEWURL. Then go through each slave repository and update its remote.REMOTENAME.url using the normal relative url mechanism.

The --fromcheckout option supports using a gits checkout as the remote repository, adjusting the repository paths from their default. The --no-fromcheckout option assumes a normal (as specified in the gits attach commands) repository layout for the remote. If neither option is given, the saved repository layout from the most recent gits populate or update-remote-url command is used; however, this is not generally correct, as the repository layout of the new remote need not be the same as the old one. If either --fromcheckout or --no-fromcheckout is given, sets the default repository layout accordingly. โญ

You can use this command after a clone of a local repository (or local gits checkout, using gits populate --fromcheckout) so that the new repository uses the same remote origin as the first one. (The local clone/populate is much faster than performing a remote clone/populate.) ๐Ÿ’…

git clone /home/user/work/wb /home/user/work/newwb
cd /home/user/work/newwb
gits populate --fromcheckout
gits update-remote-url --no-fromcheckout origin ssh://git/src/git/wb

๐ŸŒŸ Add a new remote to all repositories

gits remote add [--[no-]fromcheckout] GIT-REMOTE-ADD-OPTS REMOTENAME REMOTEURL

Adds a remote named REMOTENAME for the repository at REMOTEURL (as modified by the relative URL rules from gits attach and gits update-remote-url and the --fromcheckout argument). The command gits fetch REMOTENAME can then be used to create and update remote-tracking branches matching REMOTENAME/*.

The superproject remote URL will be set to REMOTEURL, which should be an absolute URL; the slave repositories will have a modified version of that URL (the layout must match that of the existing remotes).

Please note that we do not currently support gits remote set-url in a useful way. See gits update-remote-url for an alternate method which will satisfy most use cases. ๐Ÿ™ˆ
gits remote add fred --fromcheckout /home/fred/src/foo
gits remote add backup ssh://backups/src/git/foo

๐Ÿš€ Push a change to a remote repository

gits push [--quick] [push args]

This is the standard git push command โ€” with the addition of a --quick option which will only attempt to push for branches which have outstanding changes. For slow connections to a large number of slave repositories, the overhead of an empty push can be large.

However, --quick only checks to see if the current branch needs to push data. If you have changes on other branches, a slow push is still required, as it is if you are pushing to a repository other than the standard origin. ๐Ÿ˜ญ

Please see SUBSTITUTION for info on how to replace part of the command with the slave repository name for each executed command.

gits push --quick
gits push otherhost:/src/work/wb/%%dir%%

๐Ÿ“ Get status on all branches

gits statuses [-m] [status args]

For each branch being tracked by the superproject, go through the list of configured slaves, check yourself out to the branch, get the git status, then switch back to the branch you were on. The output is summarized for each branch to merge the lists of files in each section.

The -m option will attempt to "move" any uncommitted changes, which may prevent failures checking out other branches, at the risk of creating conflicts, which are then moved as well.

Other args supported by git status are also supported; these are the same options supported by git commit. ๐Ÿ’–

gits statuses

๐ŸŒˆ Make an archive of the repositories

gits archive GIT-ARCHIVE-ARGS

This is the standard git archive command โ€” with the addition of a new --format option of "gits-tar". When you select the gits-tar option, you must supply an on-disk --output file and you cannot use any tar compression options. With gits-tar, the output tar archive will be a unified archive of the entire project, superproject and slaves. Any existing prefix will be treated as a directory prefix (e.g. --prefix foo and --prefix foo/ are the same) and all slave repositories will be unpacked in their corresponding superproject locations.

If you choose a format other than gits-tar, you will probably want to use one of the substitutions like %%basename%% or %%dir%% in the output filename. ๐ŸŽ€

โœจ Everything else โœจ

gits archive --format gits-tar -o /tmp/foo.tar master

gits archive --format tar -o /tmp/foo-%%basename%%.tar master

okay and for literally everything else? ๐Ÿซถ every other command gets passed straight through to git, with one command being run per repository. and then the output gets summarized so that multiple repos spitting out the same git output only show it to you once โ€” no cap, so efficient ๐Ÿ’…. git status gets an even more aggressive summarizing that merges the lists of files in each section. iconic behavior.

Examples:

gits commit -a -m "This is a change"
gits push
gits pull
gits branch testing
gits checkout testing
gits diff master testing
gits status
gits ....

so like, all normal git commands are supported (plus any potential future commands, we love a forward-compatible queen ๐Ÿ‘‘) โ€” but NOT all commands make sense to run with gits. one good example is git-daemon, which is giving "girl why are you like this" ๐Ÿ˜ญ.


๐Ÿ’… DESCRIPTION ๐Ÿ’…

here's the whole options menu, no gatekeeping, read it like your life depends on it โœจ

๐ŸŒธ --parallel=COUNT, -p COUNT

specify the number of parallel git operations you wish to execute ๐Ÿ”ฅ. heads up though: parallelism is only activated for push and pull(s) subcommands. but when it kicks in it can speed up your processing significantly for large numbers of slave repositories. highkey a glow-up for big setups.

if your remote repositories are accessed over ssh, you may also wish to activate ssh ControlMaster multiplexing:

Host git
   ControlMaster auto
   ControlPath ~/.ssh/master-%r@%h:%p
โš ๏ธ but bestie there currently is a auto race condition, so the first batch of peers do not necessarily take advantage of the multiplexing, and there have occasionally been spurious errors with this enabled. so like... proceed with awareness ๐Ÿ™ˆ

๐ŸŒธ --verbose, -v

ask for more information about what is happening ๐Ÿ‘€. you may repeat the flag multiple times to get more information:

  • one level of verbosity (-v) will print some minor warnings and will specify every repository and its output explicitly
  • two levels (-vv) will print the underlying commands being executed
  • three levels (-vvv) will print the data being returned from them

so yes, you can absolutely go full detective mode ๐Ÿ”.

๐ŸŒธ --quiet

ask for less information ๐Ÿ˜Œ, which currently means discarding the STDERR of some of the administrative git commands which are executed. shhh. quiet hours.

๐ŸŒธ --rawout

do not go through output summarization (On repo and leading spaces) for most gitslave commands. note that the output may currently not be in the same repository order as it was originally ๐Ÿซ . implies --no-hide.

often used for post-processing output. example:

rsync -aR `gits --rawout exec sh -c 'git ls-tree -r --name-only HEAD | sed "s:^:%%dir%%/:"'` otherhost:/otherdir

๐ŸŒธ --help

print gits usage summary and details of gits options and substitutions from this documentation, then exit. the classic "help me help you" move ๐Ÿ’–

๐ŸŒธ --version

print version information for gits, git, and Perl. three icons, one command โญ

๐ŸŒธ --paginate, --no-pager, -n

disable or re-enable default pagination of gits output using a pager ๐Ÿ“„. the pager (default is less) and its options are configured just as for git itself โ€” using core.pager in the master repository or global settings, or environment variables PAGER or GIT_PAGER, with the same precedence.

pagination is only enabled if standard output is a tty (and there is a controlling tty for the pager to take input from). pagination is disabled if the configured pager (from config and environment) is set to the value cat or the empty string.

the -n option will disable pagination, but will be overridden by any --paginate or --no-pager arguments present on the command line, even if the -n option is given later. so order matters, bestie โ€” read the room ๐Ÿ˜ค

๐ŸŒธ --eval-args

when quoting gits arguments, do not quote dollar $ and backtick ` characters, to allow interpolation in the slave environment (but still quote double-quote and backslash) ๐Ÿงš. this is mostly useful for exec, where you might want something like the command below to do something useful:

gits --eval-args exec echo Directory is '`pwd`'

๐ŸŒธ --exclude=SLAVE-REGEXP

provide a regular expression which excludes those slaves from consideration from gits commands which it matches ๐Ÿšซ. bye felicia.

๐ŸŒธ --keep-going

do not abort when any subsidiary git command fails โ€” instead print a warning and continue processing ๐Ÿซถ. but ngl, some git command failures will still be considered fatal and cause gits to abort. so it's a vibe, not a guarantee.

๐ŸŒธ --no-commit

this flag requests that gits-internal sub-commands, such as prepare or attach, should not commit their changes after they make them. hands off the commit button ๐Ÿ”ฅ

๐ŸŒธ --no-hide

this flag requests that gits not hide information when similar (but not identical) output such as commit hashes is output for slave repositories. show me everything, I can handle it ๐Ÿ‘‘

๐ŸŒธ --no-progress

this flag requests that gits NOT print a progress bar, which it does by default for slow operations if Term::ProgressBar is loaded ๐Ÿ“Š. slow operations are the checkout, fetch, pull(s), and push subcommands. you may use this flag for all operations.

๐ŸŒธ --no-master

this flag requests that gits only run the listed command on the slave repositories and NOT the super/master/top repository. master said not today ๐Ÿ’…

๐ŸŒธ --with-ifpresent

operate also on those slave repositories which are marked as "ifpresent" even if they are not present ๐Ÿฆ‹. this is mostly useful for gits populate and gits checkout.

๐ŸŒธ --just-ifpresent

operate only on those slave repositories which are marked as "ifpresent", whether they are present or not ๐ŸŒˆ. this is mostly useful for gits release. note that this implies --no-master, and overrides --with-ifpresent. so yeah, it wins the argument ๐Ÿ˜Œ

๐ŸŒธ SUBCOMMAND [ARGS]...

run the specified git command (with associated arguments) on the repository and all slave repositories. typically they are git commands run over each slave, but there are gits-specific commands such as: pulls, prepare, attach, populate, resolve, exec, logs, and update-remote-url. see OVERVIEW for more information on specific subcommands ๐Ÿ“š.


๐Ÿ”ฎ SUBSTITUTION ๐Ÿ”ฎ

before execution, essentially all commands running over all of the repositories will go through a substitution phase where certain magic tokens will be replaced with information about the repository in question โœจ. these are most often used with gits exec and gits archive.

  • %%dir%% โ€” represents the on-disk .gitslave-relative of the repository (e.g. the second field in .gitslave) with the superproject getting the value of . ๐ŸŽ€
  • %%path%% โ€” represents the fully qualified path to the repository in question
  • %%basename%% โ€” represents the basename of the %%path%%, which is typically the last component of %%dir%% except for the superproject, for which it is whatever the last directory name of the path to the superproject ๐Ÿ’–
  • %%upstream%% โ€” represents the URL to the origin repository for the repository in question
  • %%upstream_base%% โ€” represents the basename to the URL to the origin repository for the repository in question

like, for example:

# Create a shadow set of bare repositories locally w/o massive transfers from origin
gits exec git clone --bare --reference=%%path%% %%upstream%% /tmp/r/%%upstream_base%%

also see --eval-args for an option to support standard shell cmd and $VARIABLE expansion where it might otherwise be quoted ๐Ÿ‘€. run the following commands to see the difference:

gits exec echo '`ls -ld $PWD`'

gits --eval-args exec echo '`ls -ld $PWD`'

๐Ÿ’€ BUGS ๐Ÿ’€

okay so the caveats, and I need you to actually listen to these:

gits changes directory to the directory where .gitslave exists ๐Ÿ“‚. likewise, when executing most git commands, gits changes directory to the root of the git slave, so any pathnames passed as arguments to gits must be absolute, not relative ๐Ÿ˜ญ. generally this is only a concern for pre-generated commit messages or things like that; you should NOT be passing gits the pathnames of files checked into git slaves โ€” you will likely get the wrong result. fr fr, don't do it.

no coding has been performed yet to handle gits remote set-url or gits branch --set-upstream ๐Ÿ™ˆ. see gits update-remote-url for a supported method to perform this operation. support could be added if necessary.

you can have partial success, failure, and repositories on which the operation was never tried, and you must recover from such manually ๐Ÿ’…. this is usually not very complicated. see --keep-going.

programs like gitk will not show the global system history. sad but true ๐Ÿซ .

special care may be needed if one or more of the repositories is a third party repository and you plan to have a complex branch/tag management strategy, plan to do (public or private) development on the third party repository, or might sometimes not want the absolute latest code on the third party branch โš ๏ธ. see the gitslave home page for more information on workarounds.

the behavior when different branches have different slave repositories associated with them and you checkout back and forth is probably not ideal (nor are any of the options we have thought of completely ideal) ๐Ÿ˜…. honest queen behavior, admitting it.


๐ŸŒธ FILES ๐ŸŒธ

๐ŸŽ€ .gitslave

the file containing the list of slave repositories (possibly in relative form) and the directories relative to the master root where they should be checked out ๐Ÿ“.

the format of this file is:

"possibly-relative-repository-path" "top-level-checkout-relative-path"[ flags]

the flags, which are optional, currently can be the value ifpresent which indicates that gits will only process this repository if the top-level-checkout-relative-path is already present โœจ.


๐Ÿฆ‹ ENVIRONMENT ๐Ÿฆ‹

๐ŸŽ€ GITSLAVE

the GITSLAVE environment variable specifies alternate location(s) of the .gitslave file ๐Ÿ’œ. note that the .gitslave file must still exist even if it is not used for this particular operation. GITSLAVE can be a filename or a list of filenames separated by comma and space; if a list of filenames is specified, it has the same effect as if the files were concatenated.

an example of a list of filenames, GITSLAVE=".gitslave, .gitslave-extras" would allow adding a supplemental list of slaves for unusual activity (e.g. release tagging) to the normal list ๐Ÿ‘‘

you can also use an alternate .gitslave file with just a subset of the slave repositories when you don't want to run commands on all of them. love a curated list ๐Ÿ’…

note that if you are using recursive gitslave superprojects, the GITSLAVE environment variable overrides .gitslave at the top-level only ๐ŸŒˆ. only if the alternate .gitslave file(s) #include .gitslave (or alternate) in recursive superprojects will their slave repositories be included.


โญ REQUIREMENTS โญ

  • perl 5 (probably almost any version of perl 5)
  • git 1.6 or later (git 1.7 or later preferred) ๐Ÿซถ
  • optionally uses Parallel::Iterator and Term::ProgressBar if available

๐Ÿ‘‘ AUTHOR ๐Ÿ‘‘

Seth Robertson ๐ŸŽ€


๐Ÿ“ฃ REPORTING BUGS ๐Ÿ“ฃ

report bugs to <http://sourceforge.net/projects/gitslave> ๐Ÿ’Œ


copyright (c) 2008 Seth Robertson. license is similar to the GNU Lesser General Public License version 2.1, see LICENSE.TXT for more details ๐Ÿ“„.

โœจ SEE ALSO โœจ

ok bestie, if ur still in ur docs-reading era (same), go peek at these:

and the Gitslave Home Page is literally right here: <http://gitslave.sf.net> ๐Ÿ’–


thatโ€™s the whole page, bestie โ€” go touch some grass or clone something iconic ๐ŸŒธ this cutie is from perl v5.42.0, dated 2024-02-27 ๐ŸŽ€โœจ

๐Ÿ“ฆ where this page comes from