some doc updates
1) talk about "git merge" instead of "git pull ."
2) suggest "git repo-config" instead of directly editing config files
3) echo "URL: blah" > .git/remotes/foo is obsolete and should be
"git repo-config remote.foo.url blah"
4) support for partial URL prefix has been removed (see commit
ea560e6d64
) so drop mention of it.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
maint
parent
adb7ba6b11
commit
c14261eaa2
|
@ -1129,46 +1129,26 @@ juggle multiple lines of development simultaneously. Of
|
||||||
course, you will pay the price of more disk usage to hold
|
course, you will pay the price of more disk usage to hold
|
||||||
multiple working trees, but disk space is cheap these days.
|
multiple working trees, but disk space is cheap these days.
|
||||||
|
|
||||||
[NOTE]
|
|
||||||
You could even pull from your own repository by
|
|
||||||
giving '.' as <remote-repository> parameter to `git pull`. This
|
|
||||||
is useful when you want to merge a local branch (or more, if you
|
|
||||||
are making an Octopus) into the current branch.
|
|
||||||
|
|
||||||
It is likely that you will be pulling from the same remote
|
It is likely that you will be pulling from the same remote
|
||||||
repository from time to time. As a short hand, you can store
|
repository from time to time. As a short hand, you can store
|
||||||
the remote repository URL in a file under .git/remotes/
|
the remote repository URL in the local repository's config file
|
||||||
directory, like this:
|
like this:
|
||||||
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
$ mkdir -p .git/remotes/
|
$ git repo-config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
|
||||||
$ cat >.git/remotes/linus <<\EOF
|
|
||||||
URL: http://www.kernel.org/pub/scm/git/git.git/
|
|
||||||
EOF
|
|
||||||
------------------------------------------------
|
|
||||||
|
|
||||||
and use the filename to `git pull` instead of the full URL.
|
|
||||||
The URL specified in such file can even be a prefix
|
|
||||||
of a full URL, like this:
|
|
||||||
|
|
||||||
------------------------------------------------
|
|
||||||
$ cat >.git/remotes/jgarzik <<\EOF
|
|
||||||
URL: http://www.kernel.org/pub/scm/linux/git/jgarzik/
|
|
||||||
EOF
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
|
|
||||||
|
and use the "linus" keyword with `git pull` instead of the full URL.
|
||||||
|
|
||||||
Examples.
|
Examples.
|
||||||
|
|
||||||
. `git pull linus`
|
. `git pull linus`
|
||||||
. `git pull linus tag v0.99.1`
|
. `git pull linus tag v0.99.1`
|
||||||
. `git pull jgarzik/netdev-2.6.git/ e100`
|
|
||||||
|
|
||||||
the above are equivalent to:
|
the above are equivalent to:
|
||||||
|
|
||||||
. `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD`
|
. `git pull http://www.kernel.org/pub/scm/git/git.git/ HEAD`
|
||||||
. `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1`
|
. `git pull http://www.kernel.org/pub/scm/git/git.git/ tag v0.99.1`
|
||||||
. `git pull http://www.kernel.org/pub/.../jgarzik/netdev-2.6.git e100`
|
|
||||||
|
|
||||||
|
|
||||||
How does the merge work?
|
How does the merge work?
|
||||||
|
@ -1546,7 +1526,8 @@ on that project and has an own "public repository" goes like this:
|
||||||
|
|
||||||
1. Prepare your work repository, by `git clone` the public
|
1. Prepare your work repository, by `git clone` the public
|
||||||
repository of the "project lead". The URL used for the
|
repository of the "project lead". The URL used for the
|
||||||
initial cloning is stored in `.git/remotes/origin`.
|
initial cloning is stored in the remote.origin.url
|
||||||
|
configuration variable.
|
||||||
|
|
||||||
2. Prepare a public repository accessible to others, just like
|
2. Prepare a public repository accessible to others, just like
|
||||||
the "project lead" person does.
|
the "project lead" person does.
|
||||||
|
@ -1586,14 +1567,15 @@ like this:
|
||||||
1. Prepare your work repository, by `git clone` the public
|
1. Prepare your work repository, by `git clone` the public
|
||||||
repository of the "project lead" (or a "subsystem
|
repository of the "project lead" (or a "subsystem
|
||||||
maintainer", if you work on a subsystem). The URL used for
|
maintainer", if you work on a subsystem). The URL used for
|
||||||
the initial cloning is stored in `.git/remotes/origin`.
|
the initial cloning is stored in the remote.origin.url
|
||||||
|
configuration variable.
|
||||||
|
|
||||||
2. Do your work in your repository on 'master' branch.
|
2. Do your work in your repository on 'master' branch.
|
||||||
|
|
||||||
3. Run `git fetch origin` from the public repository of your
|
3. Run `git fetch origin` from the public repository of your
|
||||||
upstream every once in a while. This does only the first
|
upstream every once in a while. This does only the first
|
||||||
half of `git pull` but does not merge. The head of the
|
half of `git pull` but does not merge. The head of the
|
||||||
public repository is stored in `.git/refs/heads/origin`.
|
public repository is stored in `.git/refs/remotes/origin/master`.
|
||||||
|
|
||||||
4. Use `git cherry origin` to see which ones of your patches
|
4. Use `git cherry origin` to see which ones of your patches
|
||||||
were accepted, and/or use `git rebase origin` to port your
|
were accepted, and/or use `git rebase origin` to port your
|
||||||
|
@ -1681,11 +1663,11 @@ $ git reset --hard master~2
|
||||||
|
|
||||||
You can make sure 'git show-branch' matches the state before
|
You can make sure 'git show-branch' matches the state before
|
||||||
those two 'git merge' you just did. Then, instead of running
|
those two 'git merge' you just did. Then, instead of running
|
||||||
two 'git merge' commands in a row, you would pull these two
|
two 'git merge' commands in a row, you would merge these two
|
||||||
branch heads (this is known as 'making an Octopus'):
|
branch heads (this is known as 'making an Octopus'):
|
||||||
|
|
||||||
------------
|
------------
|
||||||
$ git pull . commit-fix diff-fix
|
$ git merge commit-fix diff-fix
|
||||||
$ git show-branch
|
$ git show-branch
|
||||||
! [commit-fix] Fix commit message normalization.
|
! [commit-fix] Fix commit message normalization.
|
||||||
! [diff-fix] Fix rename detection.
|
! [diff-fix] Fix rename detection.
|
||||||
|
@ -1701,7 +1683,7 @@ $ git show-branch
|
||||||
|
|
||||||
Note that you should not do Octopus because you can. An octopus
|
Note that you should not do Octopus because you can. An octopus
|
||||||
is a valid thing to do and often makes it easier to view the
|
is a valid thing to do and often makes it easier to view the
|
||||||
commit history if you are pulling more than two independent
|
commit history if you are merging more than two independent
|
||||||
changes at the same time. However, if you have merge conflicts
|
changes at the same time. However, if you have merge conflicts
|
||||||
with any of the branches you are merging in and need to hand
|
with any of the branches you are merging in and need to hand
|
||||||
resolve, that is an indication that the development happened in
|
resolve, that is an indication that the development happened in
|
||||||
|
|
|
@ -148,8 +148,7 @@ modification will be caught if you do `git commit -a` later.
|
||||||
<8> redo the commit undone in the previous step, using the message
|
<8> redo the commit undone in the previous step, using the message
|
||||||
you originally wrote.
|
you originally wrote.
|
||||||
<9> switch to the master branch.
|
<9> switch to the master branch.
|
||||||
<10> merge a topic branch into your master branch. You can also use
|
<10> merge a topic branch into your master branch.
|
||||||
`git pull . alsa-audio`, i.e. pull from the local repository.
|
|
||||||
<11> review commit logs; other forms to limit output can be
|
<11> review commit logs; other forms to limit output can be
|
||||||
combined and include `\--max-count=10` (show 10 commits),
|
combined and include `\--max-count=10` (show 10 commits),
|
||||||
`\--until=2005-12-10`, etc.
|
`\--until=2005-12-10`, etc.
|
||||||
|
|
|
@ -52,7 +52,8 @@ git pull origin next::
|
||||||
|
|
||||||
git pull . fixes enhancements::
|
git pull . fixes enhancements::
|
||||||
Bundle local branch `fixes` and `enhancements` on top of
|
Bundle local branch `fixes` and `enhancements` on top of
|
||||||
the current branch, making an Octopus merge.
|
the current branch, making an Octopus merge. This `git pull .`
|
||||||
|
syntax is equivalent to `git merge`.
|
||||||
|
|
||||||
git pull -s ours . obsolete::
|
git pull -s ours . obsolete::
|
||||||
Merge local branch `obsolete` into the current branch,
|
Merge local branch `obsolete` into the current branch,
|
||||||
|
|
|
@ -81,7 +81,7 @@ One way to do it is to pull master into the topic branch:
|
||||||
|
|
||||||
------------
|
------------
|
||||||
$ git checkout topic
|
$ git checkout topic
|
||||||
$ git pull . master
|
$ git merge master
|
||||||
|
|
||||||
o---*---o---+ topic
|
o---*---o---+ topic
|
||||||
/ /
|
/ /
|
||||||
|
@ -103,10 +103,10 @@ in which case the final commit graph would look like this:
|
||||||
|
|
||||||
------------
|
------------
|
||||||
$ git checkout topic
|
$ git checkout topic
|
||||||
$ git pull . master
|
$ git merge master
|
||||||
$ ... work on both topic and master branches
|
$ ... work on both topic and master branches
|
||||||
$ git checkout master
|
$ git checkout master
|
||||||
$ git pull . topic
|
$ git merge topic
|
||||||
|
|
||||||
o---*---o---+---o---o topic
|
o---*---o---+---o---o topic
|
||||||
/ / \
|
/ / \
|
||||||
|
@ -126,11 +126,11 @@ top of the tip before the test merge:
|
||||||
|
|
||||||
------------
|
------------
|
||||||
$ git checkout topic
|
$ git checkout topic
|
||||||
$ git pull . master
|
$ git merge master
|
||||||
$ git reset --hard HEAD^ ;# rewind the test merge
|
$ git reset --hard HEAD^ ;# rewind the test merge
|
||||||
$ ... work on both topic and master branches
|
$ ... work on both topic and master branches
|
||||||
$ git checkout master
|
$ git checkout master
|
||||||
$ git pull . topic
|
$ git merge topic
|
||||||
|
|
||||||
o---*---o-------o---o topic
|
o---*---o-------o---o topic
|
||||||
/ \
|
/ \
|
||||||
|
|
|
@ -11,15 +11,13 @@ diff" with:
|
||||||
$ man git-diff
|
$ man git-diff
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
|
|
||||||
It is a good idea to introduce yourself to git before doing any
|
It is a good idea to introduce yourself to git with your name and
|
||||||
operation. The easiest way to do so is:
|
public email address before doing any operation. The easiest
|
||||||
|
way to do so is:
|
||||||
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
$ cat >~/.gitconfig <<\EOF
|
$ git repo-config --global user.name "Your Name Comes Here"
|
||||||
[user]
|
$ git repo-config --global user.email you@yourdomain.example.com
|
||||||
name = Your Name Comes Here
|
|
||||||
email = you@yourdomain.example.com
|
|
||||||
EOF
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
|
|
||||||
|
|
||||||
|
@ -211,7 +209,7 @@ at this point the two branches have diverged, with different changes
|
||||||
made in each. To merge the changes made in experimental into master, run
|
made in each. To merge the changes made in experimental into master, run
|
||||||
|
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
$ git pull . experimental
|
$ git merge experimental
|
||||||
------------------------------------------------
|
------------------------------------------------
|
||||||
|
|
||||||
If the changes don't conflict, you're done. If there are conflicts,
|
If the changes don't conflict, you're done. If there are conflicts,
|
||||||
|
@ -316,14 +314,14 @@ shows a list of all the changes that Bob made since he branched from
|
||||||
Alice's master branch.
|
Alice's master branch.
|
||||||
|
|
||||||
After examining those changes, and possibly fixing things, Alice
|
After examining those changes, and possibly fixing things, Alice
|
||||||
could pull the changes into her master branch:
|
could merge the changes into her master branch:
|
||||||
|
|
||||||
-------------------------------------
|
-------------------------------------
|
||||||
$ git checkout master
|
$ git checkout master
|
||||||
$ git pull . bob-incoming
|
$ git merge bob-incoming
|
||||||
-------------------------------------
|
-------------------------------------
|
||||||
|
|
||||||
The last command is a pull from the "bob-incoming" branch in Alice's
|
The last command is a merge from the "bob-incoming" branch in Alice's
|
||||||
own repository.
|
own repository.
|
||||||
|
|
||||||
Alice could also perform both steps at once with:
|
Alice could also perform both steps at once with:
|
||||||
|
|
Loading…
Reference in New Issue