From bff39f01584807b55b40ad6bb55e517094ac6d52 Mon Sep 17 00:00:00 2001 From: Ben Lynn Date: Mon, 14 Apr 2008 02:25:46 -0700 Subject: [PATCH] Minor edits. --- basic.txt | 4 ++-- branch.txt | 7 ++++--- secrets.txt | 18 +++++++++++++----- 3 files changed, 19 insertions(+), 10 deletions(-) diff --git a/basic.txt b/basic.txt index 1ea06cf..4d310f1 100644 --- a/basic.txt +++ b/basic.txt @@ -56,7 +56,7 @@ Other times you want to hop to an old state briefly. In this case, type: This takes you back in time, while preserving newer commits. However, like time travel in a science-fiction movie, if you now edit and commit, you will be in an alternate reality, because your actions are different to what they were the first time around. -This alternate reality is called a branch, and we'll have more to say about that later. For now, just remember that +This alternate reality is called a ''branch'', and <>. For now, just remember that $ git checkout master @@ -68,7 +68,7 @@ To take the computer game analogy again: - *`git reset \--hard`*: load an old save and delete all saved games newer than the one just loaded. -- *`git checkout`*: load an old game, but if you play on, the game state will deviate from the newer saves you made the first time around. Any saved games you make now will end up in a separate branch representing the alternate reality you have entered. We describe how to deal with this later. +- *`git checkout`*: load an old game, but if you play on, the game state will deviate from the newer saves you made the first time around. Any saved games you make now will end up in a separate branch representing the alternate reality you have entered. <>. You can choose only to restore particular files and subdirectories by appending them after the command. diff --git a/branch.txt b/branch.txt index 30e3f31..7e1ad18 100644 --- a/branch.txt +++ b/branch.txt @@ -41,22 +41,23 @@ You can switch between the two versions of the file as much as you like, and com === Dirty Work === +[[branch]] Say you're working on some feature, and for some reason, you need to go back to an old version and temporarily put in a few prints statements to see how something works. Then: $ git commit -a $ git checkout SHA1_HASH -Now you can add ugly temporary code all over the place. When you're done, +Now you can add ugly temporary code all over the place. You can even commit these changes. When you're done, $ git checkout master -to return to your original work and remove all traces of the temporary code. +to return to your original work. Observe that any uncommitted changes are carried over. What if you wanted to save the temporary changes after all? Easy: $ git checkout -b dirty -before switching back to the master branch. Whenever you want to return to the dirty changes, simply type +and commit before switching back to the master branch. Whenever you want to return to the dirty changes, simply type $ git checkout dirty diff --git a/secrets.txt b/secrets.txt index 16c5a69..a5d1164 100644 --- a/secrets.txt +++ b/secrets.txt @@ -20,12 +20,16 @@ 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. The contents of files are strings of bytes we call ''blobs'' and they are divorced from their filenames. +Roughly speaking, all files handled by Git are referred to by their unique ID, not by their filename. 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 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. +You can see for yourself: take any hash you see in the `.git/objects` directory, and type + + $ git cat-file -p SHA1_HASH + 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 link:.[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. @@ -47,9 +51,9 @@ Most Git commands expect the Git index to live in ".git", and will fail on these 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! -==== Windows Git ==== +==== Microsoft Windows ==== -Git on Window can be cumbersome. It works with Cygwin installed, though is slower. There is also a http://repo.or.cz/w/git/mingw.git[mingw port] whose setup is less invasive as it can be run from the Windows command-line. +Git on Windows can be cumbersome. It works with Cygwin installed, though is slower. There is also the less invasive http://repo.or.cz/w/git/mingw.git[mingw port] which can be run from the Windows command-line. ==== Unrelated Files ==== @@ -67,7 +71,11 @@ The reasons why the changes are so great should be examined. Perhaps file format Or perhaps a database or backup/archival solution is what is actually being sought, not a version control system. For example, version control may not be suitable for managing photos periodically taken from a webcam. Again, version control is meant for keeping track of alterations made by humans. -If the files really must be constantly morphing and a version control really must be used, a possibility is to use Git in a centralized fashion. With some simple scripting, one can checkout files without their histories. Of course, most Git tools will be unavailable. This is probably fine as it's unclear how the history of wildly unstable files can help anyone. +If the files really must be constantly morphing and they really must be versioned, a possibility is to use Git in a centralized fashion. One can create shallow clones, which checks out little or no history of the project. Of course, many Git tools will be unavailable, and fixes must be submitted as patches. This is probably fine as it's unclear why anyone would want the history of wildly unstable files. + +Another example is a project depending on firmware, which takes the form of a huge binary file. The history of the firmware is uninteresting to users, and updates compress poorly, so firmware revisions would unnecessarily blow up the size of the repository. + +In this case, the source code should be stored in a Git repository, and the binary file should be kept separately. To make life easier, one could distribute a script that uses Git to checkout the code, and rsync for the firmware. ==== Global Counter ==== @@ -75,7 +83,7 @@ Some centralized version control systems maintain a positive integer that increa But some people like having this integer around. Luckily, it's easy to write scripts so that with every update, the central Git repository increments an integer, perhaps in a tag, and associates it with the hash of the latest commit. -Actually, every clone could maintain such a counter, but this would probably not be useful, since everyone only really cares about the central repository and its counter. +Every clone could maintain such a counter, but this would probably not be useful, since everyone only really cares about the central repository and its counter. ==== Automatic Compression ==== -- 2.11.4.GIT