From 52bcfc8ebb44bd7c35eed72a73dbcd98dbf3b7ee Mon Sep 17 00:00:00 2001 From: Ben Lynn Date: Tue, 4 Sep 2007 03:02:05 -0700 Subject: [PATCH] Added section on rename and copy detection Added git-commit --amend trick Fixed bug in script causing blocks to be closed prematurely --- grandmaster.txt | 8 ++++++++ secrets.txt | 22 ++++++++++++++-------- wiki2xml | 2 +- 3 files changed, 23 insertions(+), 9 deletions(-) diff --git a/grandmaster.txt b/grandmaster.txt index b9a1e9f..78856f9 100644 --- a/grandmaster.txt +++ b/grandmaster.txt @@ -51,6 +51,14 @@ If you have a big list of directories and files that should never be version con $ git-ls-files -d -m -o -X ignore | xargs git-update-index --add --remove +== I Stand Corrected == + +Did you just commit, but wish you had typed a different message? Realized you forgot to add a file? Then: + + $ git commit --amend + +can help you out. + == Building On Git == In true UNIX fashion, Git's design allows it to be easily used as a low-level component of other programs. There are GUI interfaces, web interfaces, alternative command-line interfaces, and perhaps soon you will have a script or two of your own that calls Git. diff --git a/secrets.txt b/secrets.txt index 21459de..55e083f 100644 --- a/secrets.txt +++ b/secrets.txt @@ -12,11 +12,6 @@ The secret is the ".git" directory in your working directory. Git keeps the hist You have total control over the fate of your files because Git doesn't care what you do to them. Git can easily recreate a saved state from ".git" at any time. -== Bare Repositories == - -You may have been wondering what format those online Git repositories use. -They're plain Git repositories, just like your ".git" directory except they've got names like "proj.git", and they have no working directory associated with them. - == Integrity == Most people associate cryptography with keeping things secret, but another equally important goal is ensuring integrity. Proper use of cryptographic hash functions can prevent accidental or malicious data corruption. @@ -25,16 +20,27 @@ A SHA1 hash can be thought of as a unique 160-bit ID number for every string of An important observation is that a SHA1 hash is itself a string of bytes, so we can hash strings of bytes containing other hashes. -Roughly speaking, all files handled by Git are referred to by their unique ID, not by their filename. You can see for yourself: all data resides in files in the ".git/objects" subdirectory, where you won't find any normal filenames. +Roughly speaking, all files handled by Git are referred to by their unique ID, not by their filename. You can see for yourself: all data resides in files in the ".git/objects" subdirectory, where you won't find any normal filenames. The contents of files are strings of bytes we call ''blobs'' and they are divorced from their filenames. -The filenames are actually recorded in ''tree'' objects, which are lists of filenames along with the IDs of their contents. Since the tree itself is a string of bytes, it too has a unique ID, which is how it is stored in the ".git/objects" subdirectory. Trees can appear on the lists of other trees, hence a directory tree and all the files within may be represented by trees and blobs. +The filenames are recorded somewhere though. They live in ''tree'' objects, which are lists of filenames along with the IDs of their contents. Since the tree itself is a string of bytes, it too has a unique ID, which is how it is stored in the ".git/objects" subdirectory. Trees can appear on the lists of other trees, hence a directory tree and all the files within may be represented by trees and blobs. Lastly, a ''commit'' contains a message, a few tree IDs and information on how they are related to each other. A commit is also a string of bytes, hence it too has a unique ID. -Now suppose somebody tries to rewrite history and attempts to change the contents of a file in an ancient version. Then the ID of the file will change since it's now a different string of bytes. This changes the ID of any tree object referencing this file, which in turn changes the ID of all commit objects involving this tree. The corruption in the bad respository is exposed when everyone realizes all the commits since the mutilated file have the wrong IDs. +Now suppose somebody tries to rewrite history and attempts to change the contents of a file in an ancient version. Then the ID of the file will change since it's now a different string of bytes. This changes the ID of any tree object referencing this file, which in turn changes the ID of all commit objects involving this tree. The corruption in the bad repository is exposed when everyone realizes all the commits since the mutilated file have the wrong IDs. I've ignored details such as file permissions and signatures. See the [[.][references]] for the full story. But in short, so long as the 20 bytes representing the last commit are safe, it's impossible to tamper with a Git repository. +== Intelligence == + +How does Git know you renamed a file, even though you never mentioned the fact explicitly? Sure you may have run *git-mv* but that is exactly the same as a *git-rm* followed by a *git-add*. + +Git heuristically ferrets out renames and copies between successive versions. Though it cannot cover all cases, it does a decent job, and this feature is always improving. + +== Bare Repositories == + +You may have been wondering what format those online Git repositories use. +They're plain Git repositories, just like your ".git" directory except they've got names like "proj.git", and they have no working directory associated with them. + == Git Shortcomings == There are some Git issues I've swept under the carpet until now. Some can be handled easily with scripts, others require reorganizing or redefining the project, and as for Windows annoyances, one will just have to wait. Or better yet, pitch in and help! diff --git a/wiki2xml b/wiki2xml index 2315f5d..e943aa0 100755 --- a/wiki2xml +++ b/wiki2xml @@ -48,8 +48,8 @@ func ul_item() { } func close_lists() { - close_block() if (in_list) { + close_block() print "" print "" in_list = 0 -- 2.11.4.GIT