Git repositories are normally totally self-sufficient and
relocatable. Unlike CVS, for example, there is no separate notion
of "repository" and "working tree". A Git repository normally is
the working tree, with the local Git information hidden in the
.git subdirectory. There is nothing else. What you see is what
you got.
Note
You can tell Git to split the Git internal information from
the directory that it tracks, but we'll ignore that for now:
it's not how normal projects work, and it's really only meant
for special uses. So the mental model of "the Git information
is always tied directly to the working tree that it
describes" may not be technically 100% accurate, but it's a
good model for all normal use.
This has two implications:
• if you grow bored with the tutorial repository you created
(or you've made a mistake and want to start all over), you
can just do simple
$ rm -rf git-tutorial
and it will be gone. There's no external repository, and
there's no history outside the project you created.
• if you want to move or duplicate a Git repository, you can do
so. There is git clone command, but if all you want to do is
just to create a copy of your repository (with all the full
history that went along with it), you can do so with a
regular cp -a git-tutorial new-git-tutorial.
Note that when you've moved or copied a Git repository, your
Git index file (which caches various information, notably
some of the "stat" information for the files involved) will
likely need to be refreshed. So after you do a cp -a to
create a new copy, you'll want to do
$ git update-index --refresh
in the new repository to make sure that the index file is up
to date.
Note that the second point is true even across machines. You can
duplicate a remote Git repository with any regular copy
mechanism, be it scp, rsync or wget.
When copying a remote repository, you'll want to at a minimum
update the index cache when you do this, and especially with
other peoples' repositories you often want to make sure that the
index cache is in some known state (you don't know what they've
done and not yet checked in), so usually you'll precede the git
update-index with a
$ git read-tree --reset HEAD
$ git update-index --refresh
which will force a total index re-build from the tree pointed to
by HEAD. It resets the index contents to HEAD, and then the git
update-index makes sure to match up all index entries with the
checked-out files. If the original repository had uncommitted
changes in its working tree, git update-index --refresh notices
them and tells you they need to be updated.
The above can also be written as simply
$ git reset
and in fact a lot of the common Git command combinations can be
scripted with the git xyz interfaces. You can learn things by
just looking at what the various git scripts do. For example, git
reset used to be the above two lines implemented in git reset,
but some things like git status and git commit are slightly more
complex scripts around the basic Git commands.
Many (most?) public remote repositories will not contain any of
the checked out files or even an index file, and will only
contain the actual core Git files. Such a repository usually
doesn't even have the .git subdirectory, but has all the Git
files directly in the repository.
To create your own local live copy of such a "raw" Git
repository, you'd first create your own subdirectory for the
project, and then copy the raw repository contents into the .git
directory. For example, to create your own copy of the Git
repository, you'd do the following
$ mkdir my-git
$ cd my-git
$ rsync -rL rsync://rsync.kernel.org/pub/scm/git/git.git/ .git
followed by
$ git read-tree HEAD
to populate the index. However, now you have populated the index,
and you have all the Git internal files, but you will notice that
you don't actually have any of the working tree files to work on.
To get those, you'd check them out with
$ git checkout-index -u -a
where the -u flag means that you want the checkout to keep the
index up to date (so that you don't have to refresh it
afterward), and the -a flag means "check out all files" (if you
have a stale copy or an older version of a checked out tree you
may also need to add the -f flag first, to tell git
checkout-index to force overwriting of any old files).
Again, this can all be simplified with
$ git clone git://git.kernel.org/pub/scm/git/git.git/ my-git
$ cd my-git
$ git checkout
which will end up doing all of the above for you.
You have now successfully copied somebody else's (mine) remote
repository, and checked it out.
