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>
This commit is contained in:
Nicolas Pitre
Junio C Hamano
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
|
||||
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
|
||||
repository from time to time. As a short hand, you can store
|
||||
the remote repository URL in a file under .git/remotes/
|
||||
directory, like this:
|
||||
the remote repository URL in the local repository's config file
|
||||
like this:
|
||||
|
||||
------------------------------------------------
|
||||
$ mkdir -p .git/remotes/
|
||||
$ 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
|
||||
$ git repo-config remote.linus.url http://www.kernel.org/pub/scm/git/git.git/
|
||||
------------------------------------------------
|
||||
|
||||
and use the "linus" keyword with `git pull` instead of the full URL.
|
||||
|
||||
Examples.
|
||||
|
||||
. `git pull linus`
|
||||
. `git pull linus tag v0.99.1`
|
||||
. `git pull jgarzik/netdev-2.6.git/ e100`
|
||||
|
||||
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/ tag v0.99.1`
|
||||
. `git pull http://www.kernel.org/pub/.../jgarzik/netdev-2.6.git e100`
|
||||
|
||||
|
||||
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
|
||||
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
|
||||
the "project lead" person does.
|
||||
@ -1586,14 +1567,15 @@ like this:
|
||||
1. Prepare your work repository, by `git clone` the public
|
||||
repository of the "project lead" (or a "subsystem
|
||||
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.
|
||||
|
||||
3. Run `git fetch origin` from the public repository of your
|
||||
upstream every once in a while. This does only the first
|
||||
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
|
||||
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
|
||||
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'):
|
||||
|
||||
------------
|
||||
$ git pull . commit-fix diff-fix
|
||||
$ git merge commit-fix diff-fix
|
||||
$ git show-branch
|
||||
! [commit-fix] Fix commit message normalization.
|
||||
! [diff-fix] Fix rename detection.
|
||||
@ -1701,7 +1683,7 @@ $ git show-branch
|
||||
|
||||
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
|
||||
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
|
||||
with any of the branches you are merging in and need to hand
|
||||
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
|
||||
you originally wrote.
|
||||
<9> switch to the master branch.
|
||||
<10> merge a topic branch into your master branch. You can also use
|
||||
`git pull . alsa-audio`, i.e. pull from the local repository.
|
||||
<10> merge a topic branch into your master branch.
|
||||
<11> review commit logs; other forms to limit output can be
|
||||
combined and include `\--max-count=10` (show 10 commits),
|
||||
`\--until=2005-12-10`, etc.
|
||||
|
||||
@ -52,7 +52,8 @@ git pull origin next::
|
||||
|
||||
git pull . fixes enhancements::
|
||||
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::
|
||||
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 pull . master
|
||||
$ git merge master
|
||||
|
||||
o---*---o---+ topic
|
||||
/ /
|
||||
@ -103,10 +103,10 @@ in which case the final commit graph would look like this:
|
||||
|
||||
------------
|
||||
$ git checkout topic
|
||||
$ git pull . master
|
||||
$ git merge master
|
||||
$ ... work on both topic and master branches
|
||||
$ git checkout master
|
||||
$ git pull . topic
|
||||
$ git merge topic
|
||||
|
||||
o---*---o---+---o---o topic
|
||||
/ / \
|
||||
@ -126,11 +126,11 @@ top of the tip before the test merge:
|
||||
|
||||
------------
|
||||
$ git checkout topic
|
||||
$ git pull . master
|
||||
$ git merge master
|
||||
$ git reset --hard HEAD^ ;# rewind the test merge
|
||||
$ ... work on both topic and master branches
|
||||
$ git checkout master
|
||||
$ git pull . topic
|
||||
$ git merge topic
|
||||
|
||||
o---*---o-------o---o topic
|
||||
/ \
|
||||
|
||||
@ -11,15 +11,13 @@ diff" with:
|
||||
$ man git-diff
|
||||
------------------------------------------------
|
||||
|
||||
It is a good idea to introduce yourself to git before doing any
|
||||
operation. The easiest way to do so is:
|
||||
It is a good idea to introduce yourself to git with your name and
|
||||
public email address before doing any operation. The easiest
|
||||
way to do so is:
|
||||
|
||||
------------------------------------------------
|
||||
$ cat >~/.gitconfig <<\EOF
|
||||
[user]
|
||||
name = Your Name Comes Here
|
||||
email = you@yourdomain.example.com
|
||||
EOF
|
||||
$ git repo-config --global user.name "Your Name Comes Here"
|
||||
$ git repo-config --global user.email you@yourdomain.example.com
|
||||
------------------------------------------------
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
------------------------------------------------
|
||||
$ git pull . experimental
|
||||
$ git merge experimental
|
||||
------------------------------------------------
|
||||
|
||||
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.
|
||||
|
||||
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 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.
|
||||
|
||||
Alice could also perform both steps at once with:
|
||||
|
||||
Loading…
Reference in New Issue
Block a user