undef/git-commit-vandalism
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation: pull/clone ref mapping clarification.

Browse Source 
Josef Weidendorfer points out that git-clone documentation does not
mention the initial copying of remote branch heads into corresponding
local branches.  Also clarify the purpose of the ref mappings description
in the "remotes" file and recommended workflow.

Signed-off-by: Junio C Hamano <junkio@cox.net>
This commit is contained in:
Junio C Hamano 2005-11-05 22:26:52 -08:00
parent b748421aaa
commit 4607166d07
2 changed files with 33 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
Documentation/git-clone.txt
View File

@ -12,7 +12,21 @@ SYNOPSIS
DESCRIPTION
-----------
Clones a repository into a newly created directory.
Clones a repository into a newly created directory. All remote
branch heads are copied under `$GIT_DIR/refs/heads/`, except
that the remote `master` is also copied to `origin` branch.
In addition, `$GIT_DIR/remotes/origin` file is set up to have
this line:
Pull: master:origin
This is to help the typical workflow of working off of the
remote `master` branch. Every time `git pull` without argument
is run, the progress on the remote `master` branch is tracked by
copying it into the local `origin` branch, and merged into the
branch you are currently working on.
OPTIONS
-------
@ -28,9 +42,10 @@ OPTIONS
--shared::
-s::
When the repository to clone is on the local machine,
instead of using hard links automatically setup
instead of using hard links, automatically setup
.git/objects/info/alternatives to share the objects
with the source repository
with the source repository. The resulting repository
starts out without any object of its own.
--quiet::
-q::
@ -49,14 +64,13 @@ OPTIONS
<repository>::
The (possibly remote) repository to clone from. It can
be an "rsync://host/dir" URL, an "http://host/dir" URL,
or [<host>:]/dir notation that is used by 'git-clone-pack'.
Currently http transport is not supported.
be any URL git-fetch supports.
<directory>::
The name of a new directory to be cloned into. It is an
error to specify an existing directory.
Author
------
Written by Linus Torvalds <torvalds@osdl.org>

21
Documentation/pull-fetch-param.txt
View File

@ -82,14 +82,19 @@ must know this is the expected usage pattern for a branch.
[NOTE]
You never do your own development on branches that appear
on the right hand side of a <refspec> colon on `Pull:` lines;
they are to be updated by `git-fetch`. The corollary is that
a local branch should be introduced and named on a <refspec>
right-hand-side if you intend to do development derived from
that branch.
This leads to the common `Pull: master:origin` mapping of a
remote `master` branch to a local `origin` branch, which
is then merged to a local development branch, again typically
named `master`.
they are to be updated by `git-fetch`. If you intend to do
development derived from a remote branch `B`, have a `Pull:`
line to track it (i.e. `Pull: B:remote-B`), and have a separate
branch `my-B` to do your development on top of it. The latter
is created by `git branch my-B remote-B` (or its equivalent `git
checkout -b my-B remote-B`). Run `git fetch` to keep track of
the progress of the remote side, and when you see something new
on the remote branch, merge it into your development branch with
`git pull . remote-B`, while you are on `my-B` branch.
The common `Pull: master:origin` mapping of a remote `master`
branch to a local `origin` branch, which is then merged to a
ocal development branch, again typically named `master`, is made
when you run `git clone` for you to follow this pattern.
+
[NOTE]
There is a difference between listing multiple <refspec>