docs: Description, synopsys, options and examples changes.
Description: Made the difference from submodules and the subtree merge strategy clearer. Synopsys and options: Synchronize with 'git subtree -h' output. I hope, properly. Examples: Added example descriptions in captions. Small fixes. Signed-off-by: John Yani <vanuan@gmail.com>
This commit is contained in:
parent
11f1511e76
commit
7f86ff0fe2
106
git-subtree.txt
106
git-subtree.txt
@ -3,50 +3,55 @@ git-subtree(1)
|
|||||||
|
|
||||||
NAME
|
NAME
|
||||||
----
|
----
|
||||||
git-subtree - add, merge, and split subprojects stored in subtrees
|
git-subtree - Merge subtrees together and split repository into subtrees
|
||||||
|
|
||||||
|
|
||||||
SYNOPSIS
|
SYNOPSIS
|
||||||
--------
|
--------
|
||||||
[verse]
|
[verse]
|
||||||
'git subtree' add --prefix=<prefix> <repository> <refspec...>
|
'git subtree' add -P <prefix>|--prefix=<prefix> <commit>
|
||||||
'git subtree' pull --prefix=<prefix> <repository> <refspec...>
|
'git subtree' pull -P <prefix>|--prefix=<prefix> <repository> <refspec...>
|
||||||
'git subtree' push --prefix=<prefix> <repository> <refspec...>
|
'git subtree' push -P <prefix>|--prefix=<prefix> <repository> <refspec...>
|
||||||
'git subtree' add --prefix=<prefix> <refspec>
|
'git subtree' merge -P <prefix>|--prefix=<prefix> <commit>
|
||||||
'git subtree' merge --prefix=<prefix> <refspec>
|
'git subtree' split -P <prefix>|--prefix=<prefix> [OPTIONS] [<commit>]
|
||||||
'git subtree' split --prefix=<prefix> <refspec...>
|
|
||||||
|
|
||||||
|
|
||||||
DESCRIPTION
|
DESCRIPTION
|
||||||
-----------
|
-----------
|
||||||
git subtree allows you to include a subproject in your
|
Subtrees allow subprojects to be included within a subdirectory
|
||||||
own repository as a subdirectory, optionally including the
|
of the main project, optionally including the subproject's
|
||||||
subproject's entire history. For example, you could
|
entire history.
|
||||||
include the source code for a library as a subdirectory of your
|
|
||||||
application.
|
|
||||||
|
|
||||||
You can also extract the entire history of a subdirectory from
|
For example, you could include the source code for a library
|
||||||
your project and make it into a standalone project. For
|
as a subdirectory of your application.
|
||||||
example, if a library you made for one application ends up being
|
|
||||||
useful elsewhere, you can extract its entire history and publish
|
|
||||||
that as its own git repository, without accidentally
|
|
||||||
intermingling the history of your application project.
|
|
||||||
|
|
||||||
Most importantly, you can alternate back and forth between these
|
Subtrees are not to be confused with submodules, which are meant for
|
||||||
two operations. If the standalone library gets updated, you can
|
the same task. Unlike submodules, subtrees do not need any special
|
||||||
|
constructions (like .gitmodule files or gitlinks) be present in
|
||||||
|
your repository, and do not force end-users of your
|
||||||
|
repository to do anything special or to understand how subtrees
|
||||||
|
work. A subtree is just a subdirectory that can be
|
||||||
|
committed to, branched, and merged along with your project in
|
||||||
|
any way you want.
|
||||||
|
|
||||||
|
They are neither not to be confused with using the subtree merge
|
||||||
|
strategy. The main difference is that, besides merging
|
||||||
|
of the other project as a subdirectory, you can also extract the
|
||||||
|
entire history of a subdirectory from your project and make it
|
||||||
|
into a standalone project. Unlike the subtree merge strategy
|
||||||
|
you can alternate back and forth between these
|
||||||
|
two operations. If the standalone library gets updated, you can
|
||||||
automatically merge the changes into your project; if you
|
automatically merge the changes into your project; if you
|
||||||
update the library inside your project, you can "split" the
|
update the library inside your project, you can "split" the
|
||||||
changes back out again and merge them back into the library
|
changes back out again and merge them back into the library
|
||||||
project.
|
project.
|
||||||
|
|
||||||
Unlike the 'git submodule' command, git subtree doesn't produce
|
For example, if a library you made for one application ends up being
|
||||||
any special constructions (like .gitmodule files or gitlinks) in
|
useful elsewhere, you can extract its entire history and publish
|
||||||
your repository, and doesn't require end-users of your
|
that as its own git repository, without accidentally
|
||||||
repository to do anything special or to understand how subtrees
|
intermingling the history of your application project.
|
||||||
work. A subtree is just another subdirectory and can be
|
|
||||||
committed to, branched, and merged along with your project in
|
|
||||||
any way you want.
|
|
||||||
|
|
||||||
|
[TIP]
|
||||||
In order to keep your commit messages clean, we recommend that
|
In order to keep your commit messages clean, we recommend that
|
||||||
people split their commits between the subtrees and the main
|
people split their commits between the subtrees and the main
|
||||||
project as much as possible. That is, if you make a change that
|
project as much as possible. That is, if you make a change that
|
||||||
@ -128,15 +133,24 @@ OPTIONS
|
|||||||
--debug::
|
--debug::
|
||||||
Produce even more unnecessary output messages on stderr.
|
Produce even more unnecessary output messages on stderr.
|
||||||
|
|
||||||
|
-P <prefix>::
|
||||||
--prefix=<prefix>::
|
--prefix=<prefix>::
|
||||||
Specify the path in the repository to the subtree you
|
Specify the path in the repository to the subtree you
|
||||||
want to manipulate. This option is currently mandatory
|
want to manipulate. This option is mandatory
|
||||||
for all commands.
|
for all commands.
|
||||||
|
|
||||||
|
-m <message>::
|
||||||
|
--message=<message>::
|
||||||
|
This option is only valid for add, merge and pull (unsure).
|
||||||
|
Specify <message> as the commit message for the merge commit.
|
||||||
|
|
||||||
OPTIONS FOR add, merge, AND pull
|
|
||||||
--------------------------------
|
OPTIONS FOR add, merge, push, pull
|
||||||
|
----------------------------------
|
||||||
--squash::
|
--squash::
|
||||||
|
This option is only valid for add, merge, push and pull
|
||||||
|
commands.
|
||||||
|
|
||||||
Instead of merging the entire history from the subtree
|
Instead of merging the entire history from the subtree
|
||||||
project, produce only a single commit that contains all
|
project, produce only a single commit that contains all
|
||||||
the differences you want to merge, and then merge that
|
the differences you want to merge, and then merge that
|
||||||
@ -169,6 +183,8 @@ OPTIONS FOR add, merge, AND pull
|
|||||||
OPTIONS FOR split
|
OPTIONS FOR split
|
||||||
-----------------
|
-----------------
|
||||||
--annotate=<annotation>::
|
--annotate=<annotation>::
|
||||||
|
This option is only valid for the split command.
|
||||||
|
|
||||||
When generating synthetic history, add <annotation> as a
|
When generating synthetic history, add <annotation> as a
|
||||||
prefix to each commit message. Since we're creating new
|
prefix to each commit message. Since we're creating new
|
||||||
commits with the same commit message, but possibly
|
commits with the same commit message, but possibly
|
||||||
@ -184,12 +200,16 @@ OPTIONS FOR split
|
|||||||
|
|
||||||
-b <branch>::
|
-b <branch>::
|
||||||
--branch=<branch>::
|
--branch=<branch>::
|
||||||
|
This option is only valid for the split command.
|
||||||
|
|
||||||
After generating the synthetic history, create a new
|
After generating the synthetic history, create a new
|
||||||
branch called <branch> that contains the new history.
|
branch called <branch> that contains the new history.
|
||||||
This is suitable for immediate pushing upstream.
|
This is suitable for immediate pushing upstream.
|
||||||
<branch> must not already exist.
|
<branch> must not already exist.
|
||||||
|
|
||||||
--ignore-joins::
|
--ignore-joins::
|
||||||
|
This option is only valid for the split command.
|
||||||
|
|
||||||
If you use '--rejoin', git subtree attempts to optimize
|
If you use '--rejoin', git subtree attempts to optimize
|
||||||
its history reconstruction to generate only the new
|
its history reconstruction to generate only the new
|
||||||
commits since the last '--rejoin'. '--ignore-join'
|
commits since the last '--rejoin'. '--ignore-join'
|
||||||
@ -198,6 +218,8 @@ OPTIONS FOR split
|
|||||||
long time.
|
long time.
|
||||||
|
|
||||||
--onto=<onto>::
|
--onto=<onto>::
|
||||||
|
This option is only valid for the split command.
|
||||||
|
|
||||||
If your subtree was originally imported using something
|
If your subtree was originally imported using something
|
||||||
other than git subtree, its history may not match what
|
other than git subtree, its history may not match what
|
||||||
git subtree is expecting. In that case, you can specify
|
git subtree is expecting. In that case, you can specify
|
||||||
@ -210,6 +232,8 @@ OPTIONS FOR split
|
|||||||
this option.
|
this option.
|
||||||
|
|
||||||
--rejoin::
|
--rejoin::
|
||||||
|
This option is only valid for the split command.
|
||||||
|
|
||||||
After splitting, merge the newly created synthetic
|
After splitting, merge the newly created synthetic
|
||||||
history back into your main project. That way, future
|
history back into your main project. That way, future
|
||||||
splits can search only the part of history that has
|
splits can search only the part of history that has
|
||||||
@ -231,8 +255,8 @@ OPTIONS FOR split
|
|||||||
subproject's history to be part of your project anyway.
|
subproject's history to be part of your project anyway.
|
||||||
|
|
||||||
|
|
||||||
EXAMPLE 1
|
EXAMPLE 1. Add command
|
||||||
---------
|
----------------------
|
||||||
Let's assume that you have a local repository that you would like
|
Let's assume that you have a local repository that you would like
|
||||||
to add an external vendor library to. In this case we will add the
|
to add an external vendor library to. In this case we will add the
|
||||||
git-subtree repository as a subdirectory of your already existing
|
git-subtree repository as a subdirectory of your already existing
|
||||||
@ -251,8 +275,8 @@ We now have a ~/git-extensions/git-subtree directory containing code
|
|||||||
from the master branch of git://github.com/apenwarr/git-subtree.git
|
from the master branch of git://github.com/apenwarr/git-subtree.git
|
||||||
in our git-extensions repository.
|
in our git-extensions repository.
|
||||||
|
|
||||||
EXAMPLE 2
|
EXAMPLE 2. Extract a subtree using commit, merge and pull
|
||||||
---------
|
---------------------------------------------------------
|
||||||
Let's use the repository for the git source code as an example.
|
Let's use the repository for the git source code as an example.
|
||||||
First, get your own copy of the git.git repository:
|
First, get your own copy of the git.git repository:
|
||||||
|
|
||||||
@ -312,22 +336,24 @@ the standard gitweb:
|
|||||||
|
|
||||||
git log gitweb-latest..$(git subtree split --prefix=gitweb)
|
git log gitweb-latest..$(git subtree split --prefix=gitweb)
|
||||||
|
|
||||||
EXAMPLE 3
|
EXAMPLE 3. Extract a subtree using branch
|
||||||
---------
|
-----------------------------------------
|
||||||
Suppose you have a source directory with many files and
|
Suppose you have a source directory with many files and
|
||||||
subdirectories, and you want to extract the lib directory to its own
|
subdirectories, and you want to extract the lib directory to its own
|
||||||
git project. Here's a short way to do it:
|
git project. Here's a short way to do it:
|
||||||
|
|
||||||
First, make the new repository wherever you want:
|
First, make the new repository wherever you want:
|
||||||
<go to the new location>
|
|
||||||
git init --bare
|
$ <go to the new location>
|
||||||
|
$ git init --bare
|
||||||
|
|
||||||
Back in your original directory:
|
Back in your original directory:
|
||||||
git subtree split --prefix=lib --annotate="(split)" -b split
|
|
||||||
|
$ git subtree split --prefix=lib --annotate="(split)" -b split
|
||||||
|
|
||||||
Then push the new branch onto the new empty repository:
|
Then push the new branch onto the new empty repository:
|
||||||
git push <new-repo> split:master
|
|
||||||
|
|
||||||
|
$ git push <new-repo> split:master
|
||||||
|
|
||||||
|
|
||||||
AUTHOR
|
AUTHOR
|
||||||
|
Loading…
Reference in New Issue
Block a user