Re: README rewrite
Here's an updated patch with fixes, apply instead of the one I just sent:
Signed-off-by: Zack Brown <zbrown@tumblerings.org>
README: needs update
Index: README
===================================================================
--- 4ef3de6ae44888d83e8c00326ddcc9f40cbd12e2/README (mode:100644)
+++ uncommitted/README (mode:100644)
@@ -1,164 +1,656 @@
- GIT - the stupid content tracker
+ Cogito
-"git" can mean anything, depending on your mood.
+Cogito is a version control system layered on top of the git
+content-tracking filesystem. This document first describes some quick ways
+to get started using Cogito, then goes over each available command one by
+one.
- - random three-letter combination that is pronounceable, and not
- actually used by any common UNIX command. The fact that it is a
- mispronunciation of "get" may or may not be relevant.
- - stupid. contemptible and despicable. simple. Take your pick from the
- dictionary of slang.
- - "global information tracker": you're in a good mood, and it actually
- works for you. Angels sing, and a light suddenly fills the room.
- - "goddamn idiotic truckload of sh*t": when it breaks
+ Quickstart
-The GIT itself is merely an extremely fast and flexible filesystem-based
-database designed to store directory trees with regard to their history.
-The top layer is a SCM-like tool Cogito which enables human beings to work
-with the database in a manner to a degree similar to other SCM tools (like
-CVS, BitKeeper or Monotone).
+ Downloading Cogito From Scratch
+
+Cogito can be obtained as a tarball from
+
+http://www.kernel.org/pub/software/scm/cogito/
+
+Download and unpack the latest version, build with make, put the executables
+somewhere in your $PATH (or add your Cogito directory itself to your $PATH),
+and you're ready to go!
+
+The following tools are required by Cogito:
+
+bash
+basic shell environment (sed, grep, textutils, ...)
+diff
+patch
+RCS (the merge program from this package)
+mktemp 1.5+ (Mandrake users beware!)
+libssl
+rsync
+libcurl
+
+ Starting A Fresh git Repository
+
+If you want to start your own project using Cogito, there are two basic ways
+to do this. You may start a fresh repository with no files in it, or you may
+take an existing directory tree and turn it into a git repository.
+
+ Starting An Empty Repository
+
+To create a new repository with no files in it, cd into an empty directory,
+and give the following command:
+
+$ cg-init
+
+Your editor will start up, and you will be asked to type in an initial
+commit description. Type something cute, and exit your editor.
+
+That's it! You're now in your own git repository. Notice there is now a git
+.directory. Go into it and look around, but don't change anything in
+there. That's what Cogito commands are for.
+
+ Turning An Existing Directory Into A Repository
+
+If you have a directory full of files, you can easily turn this into a
+git repository. In fact, it is virtually the same as starting an empty
+repository. Just cd into the directory you want converted into a git
+repository, and give the following command:
+
+$ cg-init
+
+Your editor starts up, you type in an initial commit message, exit your
+editor, and you're good to go. All of the files and directories within that
+directory are now part of a git archive.
+
+ Accessing Someone Else's git Repository
+
+ Creating The Repository
+
+If you want to get started tracking an outside git repository, you first
+must have Cogito's executables on your $PATH. Next, you need the URL (or
+local directory path) of the repository you want to track. You can't just
+use the URL of a tarball, like the one given above for the Cogito source.
+The URL must point specifically to a .git directory somewhere. For instance,
+the URL for Cogito's self-hosting repository is
+
+rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
+
+Notice that the final filename, 'cogito.git', is not called '.git'. That is
+fine. It's still a .git directory.
+
+To clone the repository to your local filesystem, use the cg-clone command.
+cg-clone can be told to create a new directory for your repository, or to
+drop the repository into the current directory.
+
+To have a new directory created, just include the directory in the command,
+as follows:
+
+$ cg-clone rsync://rsync.kernel.org/pub/scm/cogito/cogito.git cogitodir
+
+You will see a whole bunch of output, and when it is over, there will be a
+new directory called 'cogitodir' (or whatever name you chose) in the current
+directory. cd into it. Because we used the Cogito URL, you will see the
+Cogito source tree, with its own .git directory keeping track of everything.
+
+If, instead, you want to clone the repository to the current directory,
+first make sure you are in an empty directory. Then give the following
+command:
+
+$ cg-clone -s rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
+
+When you get your prompt back, do an ls to see the source tree and .git
+directory.
+
+ Tracking The Repository
+
+Of course, once you have cloned a repository, you don't just want to leave
+it at that. The upstream sources are constantly being updated, and you want
+to follow these updates. To do this, cd into the repository directory (not
+the .git directory, but the directory that contains the .git directory), and
+give the following command:
+
+$ cg-update
+
+You don't use a URL anymore. Cogito knows which tree you're tracking,
+because this information is stored in the .git directory. The above command
+will track the 'origin' branch, which is the primary branch of development.
+But cg-update can also be used to track specific branches. See below for
+more discussion of branches, and how to track them.
+
+When you give the above cg-update command, this performed two actions.
+First, it pulled all new changes from the upstream repository into your
+local repository. At that point, the changes exist in your local repository
+as part of the project's history. The changes themselves are not actually
+visible in the files you see, but reside in the .git directory's awareness.
+The second thing cg-update does is to merge these changes into the files you
+see and work with. The end result is that, when the cg-update has finished,
+you will see all the upstream changes reflected in your local files, and the
+.git directory will be aware of the history of those changes as well.
+
+It may be that you want to be aware of the history of the upstream work, but
+you don't yet want those changes merged with your own local files. To do
+this, give the following command:
+
+$ cg-pull
+
+This does the first part of cg-update's behavior, but skips the second part.
+Now your local files have not been changed, but your .git directory has been
+updated with the history of all the changes that have occurred in the
+upstream sources.
+
+Using cg-pull is useful for a variety of purposes, for instance if you want
+to construct a diff against the latest version of the upstream sources, but
+don't want those changes to disturb your ongoing work. cg-pull will update
+your .git directory with the history you need to construct your diff,
+without merging that history into your tree, potentially breaking your
+changes.
+
+Typically, if you are not making changes to a repository yourself, but just
+want the latest version of a given project for your own use, you would use
+cg-update. cg-pull is strictly for development work.
+
+Once you've done a cg-pull, you may decide you want to merge after all. In
+this case a cg-update command will do the trick, however you will also
+update your local files with any further upstream changes that have occurred
+since your cg-pull.
+
+ Getting Help
+
+Cogito commands come with their own helpful documentation. To get help on
+cg-update, for example, give this command:
+
+$ cg-pull --help
+
+or, for the same information, try this:
+
+$ cg-help cg-pull
+
+ Command Reference
+
+ Caveats
+
+ What are those cg-Xes?
+
+There are three executables, cg-Xdiffdo, cg-Xlib, and cg-Xmergefile, that
+are not meant to be used from the command line. They provide a library of
+generic functions used by many of the real cg-* commands. You can safely
+ignore them, unless you want to contribute to Cogito development.
+
+ What about file renames?
+
+File renaming (and tracking the history of a file from name to name) is
+being worked on. git provides a wonderful, elegant way to track content as
+it moves from file to file, and renames should be a special case of this.
+
+ Can I give Cogito commands from a subdirectory?
+
+Cogito currently requires that commands be given from the base directory,
+the one containing the .git directory. Patches have been submitted to
+implement the ability to give Cogito commands from subdirectories within the
+repository, but Linus prefers the current behavior.
+
+ cg-add
+
+This command is used to add files to the git repository. It takes a list of
+files on the command line, and schedules them for addition. To actually add
+them, however, you must subsequently give a cg-commit command.
+
+$ cg-add file1 file2 dir1/file3 dir1/file4 dir2/dir3/file5
+
+The above command schedules file1, file2, file3, file4, and file5 to be
+added to the repository at the next cg-commit.
+
+Notice that you never need to add directories to a repository, in fact
+Cogito won't let you. Directories are added automatically when you add the
+files that are inside them. So you can do something like this:
+
+$ mkdir testdir
+$ echo "testtext" > testdir/testfile
+$ cg-add testdir/testfile
+$ cg-commit
+
+and the testdir directory and testfile file will both be added to the
+repository. If you then do a cg-seek to look at an earlier version of the
+repository, both the file and the directory will be gone.
+
+ cg-admin-lsobj
+
+STUB
+
+ cg-admin-uncommit
+
+STUB
+
+ cg-branch-add
+
+STUB
+
+ cg-branch-ls
+
+STUB
+
+ cg-cancel
+
+This undoes all the changes you have made but not committed to your
+repository. Changes you have already committed are kept. All others are
+reverted to their previous form.
+
+If you have given any cg-add commands, these are also undone in the sense
+that the files and directories will no longer be added on a cg-commit. The
+files and directories themselves are not deleted by a cg-cancel.
+
+ cg-clone
+
+This checks out a remote repository into a local filesystem. It is only used
+for the initial creation of the local repository. Subsequent updates to
+track the upstream sources are done with cg-update or cg-pull.
+
+In its simplest form, cg-clone takes a URL or directory path to a remote
+repository:
+
+$ cg-clone rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
+The above command interprets the URL and takes the base directory (in this
+case 'cogito') as the target for the new repository. If the directory
+already exists within the current directory, cg-clone exits with an error
+message. Otherwise this directory is created within the current directory.
+cg-clone then clones the upstream repository into that directory.
+It's also possible to specify the target directory by hand on the command
+line, as follows:
- Cogito
- ~~~~~~
+$ cg-clone rsync://rsync.kernel.org/pub/scm/cogito/cogito.git targetdir
-This currently simply describes what should you do when you get a tarball
-of Cogito and start to use it and hack upon it. It can give you some guide,
-but the documentation should be certainly consolidated and rewritten.
+If targetdir already exists, cg-clone will exit again with an error message.
+Otherwise, targetdir is created, and the upstream repository is cloned into
+it.
-Build it by make, make sure the scripts are in $PATH.
+If you want to clone the upstream sources into the current directory, use
+the -s option:
-If, after unpacking the tarball, you do not have the .git subdirectory in the
-tarball root, you
+$ cg-clone -s rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
- cg-clone -s rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
+This will not create a new directory anywhere, but will just create the
+repository directly into the current directory. Any files or directories
+already in the current directory will not be overwritten, and files of the
+same name will retain their old contents. Typically, you never want to use
+the -s option in a directory with existing files or subdirectories.
-in that directory, and
+ cg-commit
- cg-branch-add pasky rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
+This command is used after you have edited files in a repository, and now
+want to include your changes in the project history. After a cg-commit, your
+changes will have a changelog entry, including your identity, the date of
+the change, and other information.
-(there is already the same branch called "origin" created by cg-clone, however
-we expect the branch name to be "pasky" for the result of the tutorial;
-alternatively, just use "origin" everywhere instead of "pasky").
+Typically you do not need to give any command line options to cg-commit, but
+just use it in its simplest form:
-If you already have the .git subdirectory, update it to the latest version by
+$ cg-commit
- cg-update pasky
+This will fire up your editor and ask for a changelog entry. If you leave
+this text blank, a changelog entry will still be created, but with no
+explanatory text. When you exit your editor, your changed files and
+changelog entry are included in the history of the repository, and are
+subject to full version control.
-(and repeat that after some time to get the future updates - but see below).
-Then build it again, doing
+There are several ways to avoid dealing with an editor at commit time.
+cg-commit accepts changelog entries from standard input:
- make
+$ echo "my first changelog entry" | cg-commit
-and... well, that's it. Play around with it a bit. ;-)
+You can also specify your changelog entry with the -m option to cg-commit:
-You can get my latest changes by doing:
+$ cg-commit -m"my first changelog entry"
- cg-update pasky
+If a changelog entry is sent via standard input, and another one is included
+in a -m option, the entry from standard input is appended with no blank line
+after the entry from the -m option.
-If you did some local commits in the meantime, Cogito will attempt to merge
-them with the pasky branch. You then need to check that the merging went
-correctly and without conflicts, possibly do merge-related fixes, and then
-record the merge with cg-commit (if the merge was clean, Cogito will commit
-automatically).
+Multiple -m options can also be given, and they will each be appended, with
+a blank line between, after the one before in the changelog entry.
-Sometimes, you will just want to bring the latest stuff from my branch, but not
-merge it (e.g. you might want only to diff against it). Do that by
+A -e option also exists, to force an editor to come up for a commit message,
+even if -m options are present, or if there is data coming from standard
+input. In this case, all input from standard input or -m options is appended
+with a blank line after the text typed into the editor.
- cg-pull pasky
+A -E option also exists and behaves identically to -e, except it will force
+the commit even if the default commit message is not changed.
-If there are any changes, two IDs will be printed (I mean the line saying
-"Tree change"). Pass those as parameters to cg-diff and you will get a diff
-describing changes from the last time you pulled. You can also
+A -C option also exists, but it is for internal purposes. You can safely
+ignore it.
- cg-diff -r pasky:HEAD
+There are several environment variables you may use to control the
+authentication information included with the changelog entry. Typically,
+Cogito uses getpwuid(getuid()) to identify the user. This can be overridden
+with these variables:
-which will show changes between my and your branch.
+GIT_AUTHOR_NAME Author's name
+GIT_AUTHOR_EMAIL Author's e-mail address
+GIT_AUTHOR_DATE Date, perhaps from a patch e-mail
+GIT_COMMITTER_NAME Committer's name
+GIT_COMMITTER_EMAIL Committer's e-mail address
-Note that you can also access the Linus' official branch, just by specifying
-'linus' instead of 'pasky'. You can of course add more branches by:
+In the above variables - and in the changelog entries - the author is the
+person who actually wrote a given patch, and the committer is the person who
+actually gave the command to include this patch in the repository. If you
+are just working on your own repository, or if you commit your own patches,
+then the author and committer are both you.
- cg-branch-add name rsyncurl
+ cg-diff
-(the rsyncurl can have a fragment part identifying a branch inside of the
-repository accessible over rsync). When you do some local changes, you can do
+This compares two trees and outputs a diff, suitable for feeding into the
+patch program. If there is no difference between the trees, cg-diff just
+outputs "ok".
- cg-diff
+With no arguments, it compares the state of your working tree, including all
+your uncommitted changes, with the state of the tree at the last commit. The
+result in this case is a diff showing only the changes you have not yet
+committed. To do this, give the following command:
-to display them. "ok" means it's identical, while hash printed means that there
-is some difference. This is a little troublesome so far, since it doesn't like
-even things like ctime or inode number (!) changed. Actual diff is printed out
-when you changed the file contents.
+$ cg-diff
-Of course you will want to commit. If you added any new files, do
+You can use the -r command to specify a single tree to compare against your
+current working directory:
- cg-add newfile1 newfile2 ...
+$ cg-diff -r 9e734775f7c22d2f89943ad6c745571f1930105f
-first. Then examine your changes by cg-diff or just show what files did you
-change by
+More generally, cg-diff can be used to produce a diff between any two SHA1
+IDs (or tags). The most common way is with a single -r command line
+argument, specifying two trees by hash IDs:
- cg-status
+$ cg-diff -r 9e734775f7c22d2f89943ad6c745571f1930105f:0397236d43e48e821cce5bbe6a80a1a56bb7cc3a
-and feel free to commit by
+The same command using tags would be:
- cg-commit
+$ cg-diff -r v2.6.12-rc2:v2.6.12-rc3
-which expects the commit message on stdin.
+Or you could use two -r commands to accomplish the same thing:
-It is nice to be able to examine the commit history. We have tool for that too.
+$ cg-diff -r v2.6.12-rc2 -r v2.6.12-rc3
- cg-log -r pasky
+Using the colon-separated form, leaving one SHA1 ID or tag name out implies
+that cg-diff should compare the specified tree to the current HEAD:
-will get you the history of my branch. cg-log with no arguments will default
-to the history of the current branch.
+$ cg-diff -r v2.6.12-rc2:
-If you want to start out new project, do (IN NEW DIRECTORY)
+compares Linux kernel version 2.6.12-rc2 with HEAD, creating a patch to
+convert the 2.6.12-rc2 tree into HEAD. To do the reverse, you simply put the
+':' at the other end of the string:
- cg-init
+$ cg-diff -r :v2.6.12-rc2
-which will also do the initial commit, importing the content of the current
-directory if there is anything in it yet.
+This command compares HEAD to Linux kernel version 2.6.12-rc2, creating a
+patch to convert HEAD into the 2.6.12-rc2 tree.
-If you want to get someone else's project, do
+The cg-diff command can also take a -p argument.
- cg-clone URL
+STUB - get more info on the -p arg
-(the URL will be available as branch "origin" for updating, etc). cg-clone
-will create new repository for its work - if you want it to work in the current
-directory (like cg-init), pass it the '-s' argument first (like in our first
-cg-clone in this tutorial).
+ cg-export
-Note that we missed out a lot of stuff here. There is already support
-for merging (cg-merge), moving your tree to an older commit (cg-seek), etc.
+This command extracts the actual project under version control and puts it
+somewhere for you. Not the revision control history but the project files
+themselves. So if you have the Linux kernel in a git repository and you give
+a cg-export command, only the kernel files themselves, not the git
+repository files, will be exported.
-For quick reference, please see
+You must specify a destination for the export on the command line. This may
+have several different interpretations:
- cg-help
+$ cg-export dirname
+In the command above, dirname is a directory name. In this case, cg-export
+exports the current state of the project to that directory.
-And for reference, my branch URL is:
+$ cg-export filename.tar
- rsync://rsync.kernel.org/pub/scm/cogito/cogito.git
+In the above, filename.tar has a '.tar' extension, and so cg-export produces
+a tarball of the current state of the project. Other recognized extensions
+are '.tar.gz', '.tgz', and '.tar.bz2'.
-Note that this all is highly experimental and is likely break frequently. You
-are advised to track LKML and/or the git mailing list.
+You may specify an additional command line argument that is an SHA1 hash ID
+(or tag), to indicate the particular version of the tree you wish to export:
+$ cg-export filename.tgz 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a
-Software requirements:
+or equivalently:
+
+$ cg-export filename.tgz v2.6.12-rc3
+
+This ability makes cg-export quite powerful. It is not just a tool for
+packaging the current state of the tree, it can package any past state as
+well.
+
+ cg-help
+
+This command is used to get help about other Cogito commands. The form is
+very simple. For instance, to get help on cg-pull, give the following
+command:
+
+$ cg-help cg-pull
+
+This is identical to giving this command as well:
+
+$ cg-pull --help
+
+Help for all other commands use an identical form.
+
+ cg-init
+
+This is used to initialize a new git repository. There are two cases: either
+you want to start a repository in an empty directory; or you want to start a
+repository in a full directory, using the existing files in that directory
+to seed the repository. In both cases the procedure is the same. Change
+directories into the directory you want to turn into the repository. Do not
+create a .git directory or anything weird like that. Just go into your
+target directory and give this command:
+
+$ cg-init
+
+Your editor will start up and you will be asked to write your first commit
+message. Make it a good one. Exit the editor. Welcome to Cogito.
+
+ cg-log
+
+This command generates changelog entries. Unless output is explicitly
+redirected, cg-log pipes all of its output to less. If invoked with no
+arguments, it shows all available changelog entries:
+
+$ cg-log
+
+You may use the -r command line argument to specify an SHA1 hash ID (or tag
+name), or a pair of these. cg-log will generate all log entries starting
+after the first, up to and including the second:
+
+$ cg-log -r v2.6.12-rc2:v2.6.12-rc3
+
+The above command shows all the log entries starting after the actual
+2.6.12-rc2 release, up to and including the entry marking the release of
+2.6.12-rc3. In other words, it produces the full changelog for 2.6.12-rc3.
+
+You may also use the -u command line argument, to specify the name - or part
+of the name - of the person who authored or committed the patch.
+
+$ cg-log -uStroesser
+
+Notice that there is no space between the -u and the name. If there are
+spaces in the name, you must use quotes, like this:
+
+$ cg-log -u"Irwin Fletcher"
+
+Whatever other arguments you give, you may also append a list of files on
+the command line. In that case, cg-log will output only the log entries of
+patches that altered those files.
+
+$ cg-log README Documentation/git.txt
+
+or
+
+$ cg-log -r v2.6.12-rc2:v2.6.12-rc3 -uLinus Makefile
+
+There are two options that control how output is displayed in cg-log. The -f
+option can be given with no arguments, to tell cg-log to include a list of
+all affected files with each changelog entry.
+
+$ cg-log -f -r v2.6.12-rc2:v2.6.12-rc3
+
+The other option to control output is -c. It can be given with no arguments,
+to cause cg-log to display its output in color.
+
+$ cg-log -c -f -r v2.6.12-rc2:v2.6.12-rc3
+
+Currently, the following changelog elements map to the following colors:
+
+header Green
+author Cyan
+committer Magenta
+files Blue
+signoff Yellow
+
+ cg-ls
+
+This command lists all the files in the repository, along with their current
+SHA1 hash ID and the type of data they represent to git (blob, tree).
+
+With no arguments, cg-ls operates on the current state of the repository. If
+given a commit ID or tree ID as a command line argument, it will list the
+files current as of that commit, or to that tree.
+
+STUB (this section needs filling out)
+
+ cg-merge
+
+STUB
+
+ cg-mkpatch
+
+STUB
+
+ cg-patch
+
+STUB
+
+ cg-pull
+
+See the quickstart section above
+
+ cg-restore
+
+STUB
+
+ cg-rm
+
+This command schedules a group of files for removal from the git repository,
+and also removes them right away from your working set of files. Although
+gone from your working set of files, the repository still considers them
+part of the tree until you give a cg-commit command.
+
+ cg-seek
+
+STUB
+
+ cg-status
+
+This command takes no arguments, and returns a list of files you have
+changed in your local tree, but that you have not yet committed with
+cg-commit. File additions and removals with cg-add and cg-rm are not listed.
+A sample usage follows:
+
+$ cg-status
+M cache.h
+$
+
+ cg-tag
+
+This command gives a convenient name of your choosing to a particular state
+of the repository, associating that name with the otherwise cumbersome hash
+ID. You may tag the current state of a repository, or you may specify a
+particular hash ID to tag from any previous state. In software development,
+a developer might tag a particular release with a version number. When Linus
+releases a new kernel, he tags it 'v2.6.12-rc4' or something similar.
+
+To tag the current state of a repository, just specify the name of the tag,
+as follows:
+
+$ cg-tag v2.6.12-rc4
+
+To tag a specific state from some time in the past, you must specify the
+SHA1 hash ID, like this:
+
+$ cg-tag v2.6.12-rc4 ebb5573ea8beaf000d4833735f3e53acb9af844c
+
+You can select a particular hash ID by looking at the 'commit' of the
+changelog entry representing the repository state you wish to tag.
+
+Tags are interchangeable with hash IDs in Cogito commands. Typically, to do
+a diff between two states of a repository, you must give a command like
+this:
+
+$ cg-diff -r 0397236d43e48e821cce5bbe6a80a1a56bb7cc3a:ebb5573ea8beaf000d4833735f3e53acb9af844c
+
+With tags, the same command can be given much more intuitively, like this:
+
+$ cg-diff -r v2.6.12-rc3:v2.6.12-rc4
+
+Both of the above examples will show you the diff between Linux kernel
+version 2.6.12-rc3 and 2.6.12-rc4.
+
+ cg-tag-ls
+
+This command takes no arguments, and lists all tags in a given repository in
+alphabetical order, along with their corresponding SHA1 hash IDs. Doing this
+on the current Cogito repository, for instance, produces the following
+output:
+
+$ cg-tag-ls
+cogito-0.10 4ed293bc0a5ffca9683e139cad499b69a4c4d569
+cogito-0.8 f9f0459b5b39cf83143c91ae39b4eaf187cf678a
+cogito-0.9 cc5517b4ea4134c296d4ce2b1d82700c44200c1e
+git-pasky-0.1 463d05c7c4fe7f24da29749f4c7f25893fc20b8c
+git-pasky-0.2 2c70421be7d88fbee49986d7a5584d1f010a25de
+git-pasky-0.3 d14925c87cdb6ca6345bcb3c8e34a2d659c79451
+git-pasky-0.4 b0bb73f33fc06cc5ff6fca0d2dfce484c5f191b7
+git-pasky-0.5 0ec59a771ff9d618a1b86e0cc1b93e3d9dad17a9
+git-pasky-0.6 b498dafca4dcc136294853d1de09fb64b0b0deea
+git-pasky-0.6.1 1690697813ffcfc35075859534a627699d07c613
+git-pasky-0.6.2 b21cee2236b494787204754960d6a5d2916dfeb4
+git-pasky-0.6.3 acc71aab89b4ae8d5f4a03c758cc4c2bc04a3229
+git-pasky-0.7 bc61d9a04dc39598014f38b0ad7422f0ceaf2cc9
+pull_from_pasky 11ed64c1b141c9ba397a1ca76aef2cd250976007
+$
+
+ cg-update
+
+See the quickstart section above.
- bash, basic shell environment (sed, grep, textutils, ...)
- diff, patch, RCS (the merge program from this package)
- mktemp 1.5+ (Mandrake users beware!)
- libssl
- rsync
- libcurl
The "core GIT"
~~~~~~~~~~~~~~
-This is a stupid (but extremely fast) directory content manager. It
+ GIT - the stupid content tracker
+
+"git" can mean anything, depending on your mood.
+
+ - random three-letter combination that is pronounceable, and not
+ actually used by any common UNIX command. The fact that it is a
+ mispronunciation of "get" may or may not be relevant.
+ - stupid. contemptible and despicable. simple. Take your pick from the
+ dictionary of slang.
+ - "global information tracker": you're in a good mood, and it actually
+ works for you. Angels sing, and a light suddenly fills the room.
+ - "goddamn idiotic truckload of sh*t": when it breaks
+
+The GIT itself is merely an extremely fast and flexible filesystem-based
+database designed to store directory trees with regard to their history.
+The top layer is a SCM-like tool Cogito which enables human beings to work
+with the database in a manner to a degree similar to other SCM tools (like
+CVS, BitKeeper or Monotone).
+
+Git is a stupid (but extremely fast) directory content manager. It
doesn't do a whole lot, but what it _does_ do is track directory
contents efficiently.