Ok, so you're a CVS user. That's ok, it's a treatable condition, and the
@ -7,7 +7,7 @@ you are reading this file means that you may be well on that path
@@ -7,7 +7,7 @@ you are reading this file means that you may be well on that path
already.
The thing about CVS is that it absolutely sucks as a source control
manager, and you'll thus be happy with almost anything else. Git,
manager, and you'll thus be happy with almost anything else. git,
however, may be a bit 'too' different (read: "good") for your taste, and
does a lot of things differently.
@ -15,7 +15,7 @@ One particular suckage of CVS is very hard to work around: CVS is
@@ -15,7 +15,7 @@ One particular suckage of CVS is very hard to work around: CVS is
basically a tool for tracking 'file' history, while git is a tool for
tracking 'project' history. This sometimes causes problems if you are
used to doing very strange things in CVS, in particular if you're doing
things like making branches of just a subset of the project. Git can't
things like making branches of just a subset of the project. git can't
track that, since git never tracks things on the level of an individual
file, only on the whole project level.
@ -32,7 +32,7 @@ and notes on converting from CVS to git.
@@ -32,7 +32,7 @@ and notes on converting from CVS to git.
Second: CVS has the notion of a "repository" as opposed to the thing
that you're actually working in (your working directory, or your
"checked out tree"). Git does not have that notion at all, and all git
"checked out tree"). git does not have that notion at all, and all git
working directories 'are' the repositories. However, you can easily
emulate the CVS model by having one special "global repository", which
people can synchronize with. See details later, but in the meantime
@ -49,7 +49,7 @@ gone through the git tutorial, and generally familiarized yourself with
@@ -49,7 +49,7 @@ gone through the git tutorial, and generally familiarized yourself with
how to commit stuff etc in git) is to create a git'ified version of your
CVS archive.
Happily, that's very easy indeed. Git will do it for you, although git
Happily, that's very easy indeed. git will do it for you, although git
will need the help of a program called "cvsps":
http://www.cobite.com/cvsps/
@ -135,7 +135,7 @@ technically possible, and there are at least two specialized scripts out
@@ -135,7 +135,7 @@ technically possible, and there are at least two specialized scripts out
there that can be used to get equivalent information (see the git
mailing list archives for details).
Git has a couple of alternatives, though, that you may find sufficient
git has a couple of alternatives, though, that you may find sufficient
or even superior depending on your use. One is called "git-whatchanged"
(for obvious reasons) and the other one is called "pickaxe" ("a tool for
the software archeologist").
@ -208,7 +208,7 @@ show anything for commits that do not touch this "if" statement.
@@ -208,7 +208,7 @@ show anything for commits that do not touch this "if" statement.
Also, in the original context, the same statement might have
appeared at first in a different file and later the file was
renamed to "a-file.c". CVS annotate would not help you to go
back across such a rename, but GIT would still help you in such
back across such a rename, but git would still help you in such
a situation. For that, you can give the -C flag to
@ -106,7 +106,7 @@ For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1
@@ -106,7 +106,7 @@ For a path that is unmerged, 'GIT_EXTERNAL_DIFF' is called with 1
parameter, <path>.
Git specific extension to diff format
git specific extension to diff format
-------------------------------------
What -p option produces is slightly different from the
@ -250,7 +250,7 @@ pattern. Filepairs that match a glob pattern on an earlier line
@@ -250,7 +250,7 @@ pattern. Filepairs that match a glob pattern on an earlier line
in the file are output before ones that match a later line, and
filepairs that do not match any glob pattern are output last.
As an example, typical orderfile for the core GIT probably
As an example, typical orderfile for the core git probably
@ -41,22 +41,22 @@ index file and all SHA1 references in .git/refs/* as heads.
@@ -41,22 +41,22 @@ index file and all SHA1 references in .git/refs/* as heads.
($GIT_DIR/objects), making sure that it is consistent and
complete without referring to objects found in alternate
object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
nor packed GIT archives found in $GIT_DIR/objects/pack;
nor packed git archives found in $GIT_DIR/objects/pack;
cannot be used with --full.
--full::
Check not just objects in GIT_OBJECT_DIRECTORY
($GIT_DIR/objects), but also the ones found in alternate
object pools listed in GIT_ALTERNATE_OBJECT_DIRECTORIES,
and in packed GIT archives found in $GIT_DIR/objects/pack
and in packed git archives found in $GIT_DIR/objects/pack
and corresponding pack subdirectories in alternate
object pools; cannot be used with --standalone.
--strict::
Enable more strict checking, namely to catch a file mode
recorded with g+w bit set, which was created by older
versions of GIT. Existing repositories, including the
Linux kernel, GIT itself, and sparse repository have old
versions of git. Existing repositories, including the
Linux kernel, git itself, and sparse repository have old
objects that triggers this check, but it is recommended
to check new projects with this flag.
@ -80,7 +80,7 @@ Any corrupt objects you will have to find in backups or other archives
@@ -80,7 +80,7 @@ Any corrupt objects you will have to find in backups or other archives
the hopes that somebody else has the object you have corrupted).
Of course, "valid tree" doesn't mean that it wasn't generated by some
evil person, and the end result might be crap. Git is a revision
evil person, and the end result might be crap. git is a revision
tracking system, not a quality assurance system ;)
@ -160,7 +160,7 @@ you'll have to use the object name, not the filename of the object:
@@ -160,7 +160,7 @@ you'll have to use the object name, not the filename of the object:
where the `-t` tells `git-cat-file` to tell you what the "type" of the
object is. Git will tell you that you have a "blob" object (ie just a
object is. git will tell you that you have a "blob" object (ie just a
regular file), and you can see the contents with
git-cat-file "blob" 557db03
@ -377,7 +377,7 @@ come from the working tree or not.
@@ -377,7 +377,7 @@ come from the working tree or not.
This is not hard to understand, as soon as you realize that git simply
never knows (or cares) about files that it is not told about
explicitly. Git will never go *looking* for files to compare, it
explicitly. git will never go *looking* for files to compare, it
expects you to tell it what the files are, and that's what the index
is there for.
================
@ -543,7 +543,7 @@ name for the state at that point.
@@ -543,7 +543,7 @@ name for the state at that point.
Copying repositories
--------------------
Git repositories are normally totally self-sufficient, and it's worth noting
git repositories are normally totally self-sufficient, and it's worth noting
that 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`
@ -950,7 +950,7 @@ This transport is the same as SSH transport but uses `sh` to run
@@ -950,7 +950,7 @@ This transport is the same as SSH transport but uses `sh` to run
both ends on the local machine instead of running other end on
the remote machine via `ssh`.
GIT Native::
git Native::
`git://remote.machine/path/to/repo.git/`
+
This transport was designed for anonymous downloading. Like SSH
@ -971,13 +971,13 @@ necessary objects. Because of this behaviour, they are
@@ -971,13 +971,13 @@ necessary objects. Because of this behaviour, they are
sometimes also called 'commit walkers'.
+
The 'commit walkers' are sometimes also called 'dumb
transports', because they do not require any GIT aware smart
server like GIT Native transport does. Any stock HTTP server
transports', because they do not require any git aware smart
server like git Native transport does. Any stock HTTP server
would suffice.
+
There are (confusingly enough) `git-ssh-fetch` and `git-ssh-upload`
programs, which are 'commit walkers'; they outlived their
usefulness when GIT Native and SSH transports were introduced,
usefulness when git Native and SSH transports were introduced,
and not used by `git pull` or `git push` scripts.
Once you fetch from the remote repository, you `resolve` that
@ -1081,7 +1081,7 @@ done only once.
@@ -1081,7 +1081,7 @@ done only once.
on the remote machine. The communication between the two over
the network internally uses an SSH connection.
Your private repository's GIT directory is usually `.git`, but
Your private repository's git directory is usually `.git`, but
your public repository is often named after the project name,
i.e. `<project>.git`. Let's create such a public repository for
project `my-git`. After logging into the remote machine, create
@ -1089,7 +1089,7 @@ an empty directory:
@@ -1089,7 +1089,7 @@ an empty directory:
mkdir my-git.git
Then, make that directory into a GIT repository by running
Then, make that directory into a git repository by running
`git init-db`, but this time, since its name is not the usual