From 0fda3349e02699d8163f3712ef50704246b9cf0f Mon Sep 17 00:00:00 2001 From: Ben Lynn Date: Tue, 18 Mar 2008 01:51:56 -0700 Subject: [PATCH] Update Google Analytics Javascript Minor edits --- branch.txt | 4 +++- custom-html.xsl | 9 ++++++--- grandmaster.txt | 2 +- intro.txt | 4 ++-- secrets.txt | 12 +++++++----- 5 files changed, 19 insertions(+), 12 deletions(-) diff --git a/branch.txt b/branch.txt index 303979d..b13f9cf 100644 --- a/branch.txt +++ b/branch.txt @@ -41,7 +41,7 @@ You can switch between the two versions of the file as much as you like, and com === Dirty Work === -Say you're working on some feature, and for some reason, you need to go back to an old version and temporarily need to put in a few prints statements to see how something works. Then: +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 @@ -98,6 +98,7 @@ Next, code the second part of the big change without waiting for the first part and the second part of the change is ready to review. But wait! What if it wasn't that simple? Say you made a mistake in the first part, which you have to correct before submitting. No problem! First, switch back to the master branch with + $ git checkout master Fix the issue with the first part of the change and hope it gets approved. If not we simply repeat this step. You'll probably want to merge the fixed version of Part I into Part II as well: @@ -107,6 +108,7 @@ Fix the issue with the first part of the change and hope it gets approved. If no Now it's the same as before. Once the first part has been approved and submitted: + $ git checkout master $ git merge part2 $ git branch -d part2 diff --git a/custom-html.xsl b/custom-html.xsl index f64af35..8ca6969 100644 --- a/custom-html.xsl +++ b/custom-html.xsl @@ -16,11 +16,14 @@ - diff --git a/grandmaster.txt b/grandmaster.txt index daf7435..5f0fd34 100644 --- a/grandmaster.txt +++ b/grandmaster.txt @@ -16,7 +16,7 @@ It's good practice to keep a http://en.wikipedia.org/wiki/Changelog[changelog], === Git Over SSH, HTTP === -Suppose you have ssh access to your web server, and it does not have Git installed, which is not an uncommon situation. Then download, compile and install Git in your account. +Suppose you have ssh access to your web server, but it does not have Git installed. Then download, compile and install Git in your account. Create a repository in your web directory: diff --git a/intro.txt b/intro.txt index e647d08..cfd75f1 100644 --- a/intro.txt +++ b/intro.txt @@ -38,11 +38,11 @@ This initial cloning operation can be expensive, especially if there's a long hi ==== A Silly Superstition ==== -A popular misconception is that distributed systems are ill-suited for projects requiring an official central repository (see for example http://www.subversionary.org/martintomes/git[this blog post]). Nothing could be further from the truth. Photographing someone does not cause their soul to be stolen. Similarly, cloning the master repository does not make its importance diminish. +A popular misconception is that distributed systems are ill-suited for projects requiring an official central repository (see for example http://www.subversionary.org/martintomes/git[this blog post]). Nothing could be further from the truth. Photographing someone does not cause their soul to be stolen. Similarly, cloning the master repository does not diminish its importance. A good first approximation is that anything a centralized version control system can do, a well-designed distributed system can do better. While not strictly true, one is less likely to make erroneous comparisons with this rule of thumb. -You might not use most features of such a system in a small project, but there is nothing wrong with this as there is negligible overhead. Moreover, your project may grow beyond your original expectations. It's like using a Swiss army knife to mostly open bottles. On the day you desperately need a screwdriver you'll be glad you have it with you. +You might not use most features of such a system in a small project, but there is nothing wrong with this as there is negligible overhead. Moreover, your project may grow beyond your original expectations. It's like carrying a Swiss army knife even though you mostly use it to open bottles. On the day you desperately need a screwdriver you'll be glad you haven't been carrying a plain bottle-opener all this time. === Merge Conflicts === diff --git a/secrets.txt b/secrets.txt index 9cc1677..4810883 100644 --- a/secrets.txt +++ b/secrets.txt @@ -14,7 +14,7 @@ You have total control over the fate of your files because Git doesn't care what === 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. +Most people associate cryptography with keeping information secret, but another equally important goal is keeping information safe. Proper use of cryptographic hash functions can prevent accidental or malicious data corruption. A SHA1 hash can be thought of as a unique 160-bit ID number for every string of bytes you'll encounter in your life. Actually more than that: every string of bytes that any human will ever use over many lifetimes. The hash of the whole contents of a file can be viewed as a unique ID number for that file. @@ -55,7 +55,7 @@ Git on Window can be cumbersome. It works with Cygwin installed, though is slowe If your project is very large and contains many unrelated files that are constantly being changed, Git may be disadvantaged more than other systems because single files are not tracked. Git tracks changes to the whole project, which is usually beneficial. -A solution is to break up your project into pieces, each consisting of related files. The *git-submodule* command can help if you still the group the pieces together. +A solution is to break up your project into pieces, each consisting of related files. Use *git-submodule* if you still want to keep everything in a single repository. ==== Volatile Projects ==== @@ -63,7 +63,7 @@ Git was written to be fast with respect to the size of the changes. Humans make There is nothing any version control system can do about this, but standard Git users will suffer more since normally histories are cloned. -The reasons why the changes are so great should be examined. Perhaps file formats should be changed. Recording minor edits should not require drastic changes to every file. +The reasons why the changes are so great should be examined. Perhaps file formats should be changed. Minor edits should only cause minor changes to at most a few files. 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. @@ -79,6 +79,8 @@ Actually, every clone could maintain such a counter, but this would probably not ==== Automatic Compression ==== -To save space, *git-gc* should be run once in a while. Some complain because this must be done manually. +To save space, *git-gc* should be run once in a while. Some complain because this must be done manually. But it is trivial to write scripts to run this program automatically. Ideally it should occur when during periods of little activity. -If this is a major concern, scripts should be written to run this program automatically. Ideally it should occur when during periods of little activity. +For working repositories, not running the git garbage collector at all may be wiser, because you can restore accidentally deleted commits. + +In this sense, the fact that you choose when garbage collection occurs is a blessing. On busy, official repositories, you can setup a script to frequently run *git-gc* while on your own machine, you might choose never to run it (so you can walways undo a mistake), and perhaps opt for an occasional *git-repack* instead. -- 2.11.4.GIT