STDIN(1) | Git Submodule Alternative | STDIN(1) |
git-subrepo - Git Submodule Alternative
git subrepo -h # Help Overview git subrepo clone <remote-url> [<subdir>] git subrepo init <subdir> git subrepo pull <subdir> git subrepo push <subdir> git subrepo fetch <subdir> git subrepo branch <subdir> git subrepo commit <subdir> git subrepo config <subdir> git subrepo status [<subdir>] git subrepo clean <subdir> git subrepo help [<command> | --all] git subrepo version git subrepo upgrade
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.
This command is an improvement from "git-submodule" and "git-subtree"; 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:
The "git-subrepo" command benefits these roles in the following ways:
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.
All the subrepo 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 not exact equivalents, and do not take all the same arguments. Keep reading…
This is similar in feel to "git clone". 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 squashed into a single commit that contains the reference information. This information is also stored in a special file called "<subdir>/.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 subdir. From the subdir, all the current information about the subrepo can be obtained.
The "--force" option will "reclone" (completely replace) an existing subdir.
The "--method" option will decide how the join process between branches are performed. The default option is merge.
The "clone" command accepts the "--branch=" "--edit", "--file", "--force" and "--message=" options.
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 "<<subdir"/.gitrepo >> file.
If you specify the "--remote" (and optionally the "--branch") option, the values will be added to the "<subdir>/.gitrepo" file. The "--remote" option is the upstream URL, and the "--branch" option is the upstream branch to push to. These values will be needed to do a "git subrepo push" command, but they can be provided later on the "push" command (and saved to "<<subdir"/.gitrepo >> if you also specify the "--update" option).
Note: You will need to create the empty upstream repo and push
to it on your
own, using "git subrepo push
<subdir>".
The "--method" option will decide how the join process between branches are performed. The default option is merge.
The "init" command accepts the "--branch=" and "--remote=" options.
The "pull" command fetches the latest content from the remote branch pointed to by the subrepo's ".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 ".gitrepo" file is updated and a single 'pull' commit is added to your mainline history.
The "pull" command will attempt to do the following commands in one go:
git subrepo fetch <subdir> git subrepo branch <subdir> git merge/rebase subrepo/<subdir>/fetch subrepo/<subdir> git subrepo commit <subdir> # Only needed for a consequential push: git update-ref refs/subrepo/<subdir>/pull subrepo/<subdir>
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 "subrepo/<subdir>" branch, which is often used for a subrepo "push" command. See 'push' below for more information. If you want to change the method you can use the "config" command for this.
When you pull you can assume a fast-forward strategy (default) or you can specify a "--rebase", "--merge" or "--force" strategy. The latter is the same as a "clone --force" operation, using the current remote and branch.
Like the "clone" command, "pull" 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 "git log" command:
git log refs/subrepo/<subdir>/fetch
The set of commands used above are described in detail below.
The "pull" command accepts the "--all", "--branch=", "--edit", "--file", "--force", "--message=", "--remote=" and "--update" options.
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 "branch" command and merge things yourself before pushing if you want to (although that is probably a rare use case).
The "push" 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 "push" after an "init"). That means the upstream HEAD is one of the commits in the branch.
By default the branch ref "refs/subrepo/<subdir>/pull" will be pushed, but you can specify a (properly merged) branch to push.
After that, the "push" command just checks that the branch contains the upstream HEAD and then pushes it upstream.
The "--force" option will do a force push. Force pushes are typically discouraged. Only use this option if you fully understand it. (The "--force" option will NOT check for a proper merge. ANY branch will be force pushed!)
The "push" command accepts the "--all", "--branch=", "--dry-run", "--file", "--force", "--merge", "--message", "--rebase", "--remote=", "--squash" and "--update" options.
It will create a Git reference called "subrepo/<subdir>/fetch" that points at the same commit as "FETCH_HEAD". It will also create a remote called "subrepo/<subdir>". These are temporary and you can easily remove them with the subrepo "clean" command.
The "fetch" command accepts the "--force", "--all", "--branch=" and "--remote=" options.
Scan the history of the mainline for all the commits that affect the "subdir" and create a new branch from them called "subrepo/<subdir>".
This is useful for doing "pull" and "push" commands by hand.
Use the "--force" option to write over an existing "subrepo/<subdir>" branch.
The "branch" command accepts the "--all", "--fetch" and "--force" options.
This command is generally used after a hand-merge. You have done a "subrepobranch" 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 "subrepo/<subdir>" branch history. That way the same branch can push upstream. Use the "--force" option to commit anyway.
The "commit" command accepts the "--edit", "--fetch", "--file", "--force" and "--message=" options.
The "--verbose" option will show all the recent local and upstream commits.
Use "--ALL" to show the subrepos of the subrepos (ie the "subsubrepos"), if any.
The "status" command accepts the "--all", "--ALL", "--fetch", "--quiet" and "--verbose" options.
The "fetch" and "branch" operations (and other commands that call them) create temporary things like refs, branches and remotes. This command removes all those things.
Use "--force" to remove refs. Refs are not removed by default because they are sometimes needed between commands.
Use "--all" to clean up after all the current subrepos. Sometimes you might change to a branch where a subrepo doesn't exist, and then "--all" won't find it. Use "--ALL" to remove any artifacts that were ever created by subrepo.
To remove ALL subrepo artifacts:
git subrepo clean --ALL --force
The "clean" command accepts the "--all", "--ALL", and "--force" options.
Because most of the values stored in the .gitrepo file are generated you will need to use "--force" if you want to change anything else then the "method" option.
Example to update the "method" option for a subrepo:
git subrepo config foo method rebase
Use "git subrepo help <command>" to get help for a specific command. Use "--all" to get a summary of all commands.
The "help" command accepts the "--all" option.
The "version" command accepts the "--quiet" and "--verbose" options.
NOTE: The "--force" option
means different things for different commands.
Read the command specific doc for the exact meaning.
The "git-subrepo" command exports and honors some environment variables:
There are currently 3 ways to install "git-subrepo". For all of them you need to get the source code from GitHub:
git clone https://github.com/ingydotnet/git-subrepo /path/to/git-subrepo
The first installation method is preferred: "source" the ".rc" file. Just add a line like this one to your shell startup script:
source /path/to/git-subrepo/.rc
That will modify your "PATH" and "MANPATH", and also enable command completion.
The second method is to do these things by hand. This might afford you more control of your shell environment. Simply add the "lib" and "man" directories to your "PATH" and "MANPATH":
export GIT_SUBREPO_ROOT="/path/to/git-subrepo" export PATH="/path/to/git-subrepo/lib:$PATH" export MANPATH="/path/to/git-subrepo/man:$MANPATH"
See below for info on how to turn on Command Completion.
The third method is a standard system install, which puts "git-subrepo" next to your other git commands:
make install # Possibly with 'sudo'
This method does not account for upgrading and command completion yet.
This command is known to work in these Windows environments:
Let us know if there are others that it works (or doesn't work) in.
The "git-subrepo" repository comes with a extensive test suite. You can run it with:
make test
or if you don't have "make" on your system:
prove -v test
If you used the ".rc" or "PATH" method of installation, just run this to upgrade "git-subrepo":
git subrepo upgrade
Or (same thing):
cd /path/to/git-subrepo git pull
If you used "make install" method, then run this again (after "git pull"):
make install # Possibly with 'sudo'
The "git subrepo" command supports "<TAB>"-based command completion. If you don't use the ".rc" script (see Installation, above), you'll need to enable this manually to use it.
If your Bash setup does not already provide command completion for Git, you'll need to enable that first:
source <Git completion script>
On your system, the Git completion script might be found at any of the following locations (or somewhere else that we don't know about):
In case you can't find any of these, this repository contains a copy of the Git completion script:
source /path/to/git-subrepo/share/git-completion.bash
Once Git completion is enabled (whether you needed to do that manually or not), you can turn on "git-subrepo" completion with a command like this:
source /path/to/git-subrepo/share/completion.bash
In the Z shell (zsh), you can manually enable "git-subrepo" completion by adding the following line to your "~/.zshrc", before the "compinit" function is called:
fpath=('/path/to/git-subrepo/share/zsh-completion' $fpath)
The git-subrepo command has been used in production and seems to get the job done. Development is still ongoing but mostly just for fixing bugs.
Trying subrepo out is simple and painless (this is not "git submodule"). Nothing is permanent (if you do not push to shared remotes). ie You can always play around and reset back to the beginning without pain.
This command has a test suite (run "make test"), but surely has many bugs. If you have expertise with Git and subcommands, please review the code, and file issues on anything that seems wrong.
If you want to chat about the "git-subrepo" command, join "#gitcommands" on "irc.freenode.net".
The MIT License (MIT)
Copyright (c) 2013-2020 Ingy döt Net
2024-07-22 | Generated by Swim v0.1.48 |