=pod
=for comment
DO NOT EDIT. This Pod was generated by Swim v0.1.48.
See http://github.com/ingydotnet/swim-pm#readme
=encoding utf8
=head1 Name
git-subrepo - Git Submodule Alternative
=for html
=head1 Synopsis
git subrepo -h # Help Overview
git subrepo clone []
git subrepo init
git subrepo pull
git subrepo push
git subrepo fetch
git subrepo branch
git subrepo commit
git subrepo config
git subrepo status []
git subrepo clean
git subrepo help [ | --all]
git subrepo version
git subrepo upgrade
=head1 Description
This git command "clones" an external git repo into a subdirectory of your
repo. Later on, upstream changes can be pulled in, and local changes can be
pushed back. Simple.
=head1 Benefits
This command is an improvement from C and C; two
other git commands with similar goals, but various problems.
It assumes there are 3 main roles of people interacting with a repo, and
attempts to serve them all well:
=over
=item * B - The person who authors/owns/maintains a repo.
=item * B - People who are just using/installing the repo.
=item * B - People who commit code to the repo and subrepos.
=back
The C command benefits these roles in the following ways:
=over
=item * Simple and intuitive commandline usage (with tab completion).
=item * Users get your repo and all your subrepos just by cloning your repo.
=item * Users do not need to install C, ever.
=item * Collaborators do not need to install unless they want to push/pull.
=item * Collaborators know when a subdir is a subrepo (it has a C<.gitrepo> file).
=item * The C<.gitrepo> file never gets pushed back to the subrepo upstream.
=item * Well named branches and remotes are generated for manual operations.
=item * Owners do not deal with the complications of keeping submodules in sync.
=item * Subrepo repositories can contain subrepos themselves.
=item * Branching with subrepos JustWorks™.
=item * Different branches can have different subrepos in different states, etc.
=item * Moving/renaming/deleting a subrepo subdir JustWorks™.
=item * You can C an existing subdirectory into a subrepo.
=item * Your git history is kept squeaky clean.
=item * Upstream history (clone/pull) is condensed into a single commit.
=item * Pulls can use a C, C or C strategies.
=item * You can see the subrepo history with C<< git log subrepo//fetch >>.
=item * Commits pushed back upstream are B condensed (by default).
=item * Trivial to try any subrepo operations and then reset back.
=item * No configuration required.
=item * Does not introduce history that messes up other git commands.
=item * Fixes known rebase failures with C.
=back
=head1 Installation
The best short answer is:
git clone https://github.com/ingydotnet/git-subrepo /path/to/git-subrepo
echo 'source /path/to/git-subrepo/.rc' >> ~/.bashrc
The complete "Installation Instructions" can be found below.
Note: git-subrepo needs a git version (> 2.7) that supports worktree:s.
=head1 Commands
All the B commands use names of actual Git commands and try to do
operations that are similar to their Git counterparts. They also attempt to
give similar output in an attempt to make the subrepo usage intuitive to
experienced Git users.
Please note that the commands are I exact equivalents, and do not take
all the same arguments. Keep reading…
=over
=item C<< git subrepo clone [] [-b ] [-f] [-m ] [-e] [--method ] >>
Add a repository as a subrepo in a subdir of your repository.
This is similar in feel to C. You just specify the remote repo url,
and optionally a sub-directory and/or branch name. The repo will be fetched
and merged into the subdir.
The subrepo history is I into a single commit that contains the
reference information. This information is also stored in a special file
called C<< /.gitrepo >>. The presence of this file indicates that the
directory is a subrepo.
All subsequent commands refer to the subrepo by the name of the
I. From the subdir, all the current information about the subrepo
can be obtained.
The C<--force> option will "reclone" (completely replace) an existing subdir.
The C<--method> option will decide how the join process between branches are
performed. The default option is merge.
The C command accepts the C<--branch=> C<--edit>, C<--force> and C<--
message=> options.
=item C<< git subrepo init [-r ] [-b ] [--method ] >>
Turn an existing subdirectory into a subrepo.
If you want to expose a subdirectory of your project as a published subrepo,
this command will do that. It will split out the content of a normal
subdirectory into a branch and start tracking it as a subrepo. Afterwards your
original repo will look exactly the same except that there will be a C<<
/.gitrepo >> file.
If you specify the C<--remote> (and optionally the C<--branch>) option, the
values will be added to the C<< /.gitrepo >> file. The C<--remote>
option is the upstream URL, and the C<--branch> option is the upstream branch
to push to. These values will be needed to do a C command,
but they can be provided later on the C command (and saved to C<<
/.gitrepo >> if you also specify the C<--update> option).
Note: You will need to create the empty upstream repo and push to it on your
own, using C<< git subrepo push >>.
The C<--method> option will decide how the join process between branches are
performed. The default option is merge.
The C command accepts the C<--branch=> and C<--remote=> options.
=item C<< git subrepo pull |--all [-M|-R|-f] [-m ] [-e] [-b ] [-r ] [-u] >>
Update the subrepo subdir with the latest upstream changes.
The C command fetches the latest content from the remote branch pointed
to by the subrepo's C<.gitrepo> file, and then tries to merge the changes into
the corresponding subdir. It does this by making a branch of the local commits
to the subdir and then merging or rebasing (see below) it with the fetched
upstream content. After the merge, the content of the new branch replaces your
subdir, the C<.gitrepo> file is updated and a single 'pull' commit is added to
your mainline history.
The C command will attempt to do the following commands in one go:
git subrepo fetch
git subrepo branch
git merge/rebase subrepo//fetch subrepo/
git subrepo commit
# Only needed for a consequential push:
git update-ref refs/subrepo//pull subrepo/
In other words, you could do all the above commands yourself, for the same
effect. If any of the commands fail, subrepo will stop and tell you to finish
this by hand. Generally a failure would be in the merge or rebase part, where
conflicts can happen. Since Git has lots of ways to resolve conflicts to your
personal tastes, the subrepo command defers to letting you do this by hand.
When pulling new data, the method selected in clone/init is used. This has no
effect on the final result of the pull, since it becomes a single commit. But
it does affect the resulting C<< subrepo/ >> branch, which is often
used for a subrepo C command. See 'push' below for more information. If
you want to change the method you can use the C command for this.
When you pull you can assume a fast-forward strategy (default) or you can
specify a C<--rebase>, C<--merge> or C<--force> strategy. The latter is the
same as a C operation, using the current remote and branch.
Like the C command, C will squash all the changes (since the last
pull or clone) into one commit. This keeps your mainline history nice and
clean. You can easily see the subrepo's history with the C command:
git log refs/subrepo//fetch
The set of commands used above are described in detail below.
The C command accepts the C<--all>, C<--branch=>, C<--edit>, C<--force>,
C<--message=>, C<--remote=> and C<--update> options.
=item C<< git subrepo push |--all [] [-r ] [-b ] [-M|-R] [-u] [-f] [-s] [-N] >>
Push a properly merged subrepo branch back upstream.
This command takes the subrepo branch from a successful pull command and
pushes the history back to its designated remote and branch. You can also use
the C command and merge things yourself before pushing if you want to
(although that is probably a rare use case).
The C command requires a branch that has been properly merged/rebased
with the upstream HEAD (unless the upstream HEAD is empty, which is common
when doing a first C after an C). That means the upstream HEAD is
one of the commits in the branch.
By default the branch ref C<< refs/subrepo//pull >> will be pushed,
but you can specify a (properly merged) branch to push.
After that, the C command just checks that the branch contains the
upstream HEAD and then pushes it upstream.
The C<--force> option will do a force push. Force pushes are typically
discouraged. Only use this option if you fully understand it. (The C<--force>
option will NOT check for a proper merge. ANY branch will be force pushed!)
The C command accepts the C<--all>, C<--branch=>, C<--dry-run>, C<--
force>, C<--merge>, C<--rebase>, C<--remote=>, C<--squash> and C<--
update> options.
=item C<< git subrepo fetch |--all [-r ] [-b ] >>
Fetch the remote/upstream content for a subrepo.
It will create a Git reference called C<< subrepo//fetch >> that
points at the same commit as C. It will also create a remote
called C<< subrepo/ >>. These are temporary and you can easily remove
them with the subrepo C command.
The C command accepts the C<--all>, C<--branch=> and C<--
remote=> options.
=item C<< git subrepo branch |--all [-f] [-F] >>
Create a branch with local subrepo commits.
Scan the history of the mainline for all the commits that affect the C
and create a new branch from them called C<< subrepo/ >>.
This is useful for doing C and C commands by hand.
Use the C<--force> option to write over an existing C<< subrepo/
>> branch.
The C command accepts the C<--all>, C<--fetch> and C<--force> options.
=item C<< git subrepo commit [] [-m ] [-e] [-f] [-F] >>
Add subrepo branch to current history as a single commit.
This command is generally used after a hand-merge. You have done a C and merged (rebased) it with the upstream. This command takes the HEAD
of that branch, puts its content into the subrepo subdir and adds a new commit
for it to the top of your mainline history.
This command requires that the upstream HEAD be in the C<< subrepo/ >>
branch history. That way the same branch can push upstream. Use the C<--force>
option to commit anyway.
The C command accepts the C<--edit>, C<--fetch>, C<--force> and C<--
message=> options.
=item C<< git subrepo status [|--all|--ALL] [-F] [-q|-v] >>
Get the status of a subrepo. Uses the C<--all> option by default. If the C<--
quiet> flag is used, just print the subrepo names, one per line.
The C<--verbose> option will show all the recent local and upstream commits.
Use C<--ALL> to show the subrepos of the subrepos (ie the
"subsubrepos"), if any.
The C command accepts the C<--all>, C<--ALL>, C<--fetch>, C<--quiet>
and C<--verbose> options.
=item C<< git subrepo clean |--all|--ALL [-f] >>
Remove artifacts created by C and C commands.
The C and C operations (and other commands that call them)
create temporary things like refs, branches and remotes. This command removes
all those things.
Use C<--force> to remove refs. Refs are not removed by default because they
are sometimes needed between commands.
Use C<--all> to clean up after all the current subrepos. Sometimes you might
change to a branch where a subrepo doesn't exist, and then C<--all> won't find
it. Use C<--ALL> to remove any artifacts that were ever created by subrepo.
To remove ALL subrepo artifacts:
git subrepo clean --ALL --force
The C command accepts the C<--all>, C<--ALL>, and C<--force> options.
=item C<< git subrepo config