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