From e2a574c7356cac767e9e75c113336e3e9bb25983 Mon Sep 17 00:00:00 2001 From: Ben Lynn Date: Thu, 6 Sep 2007 14:24:58 -0700 Subject: [PATCH] More salesmanship in branch chapter Added -z, -0 to "Commit What Changed" Minor edits --- basic.txt | 6 ++++-- branch.txt | 10 +++++----- clone.txt | 20 ++++++-------------- grandmaster.txt | 8 ++++---- intro.txt | 8 ++++++++ 5 files changed, 27 insertions(+), 25 deletions(-) diff --git a/basic.txt b/basic.txt index f670071..d181a01 100644 --- a/basic.txt +++ b/basic.txt @@ -76,6 +76,8 @@ To take the computer game analogy again: - *git-checkout* is like loading 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. +For reset and checkout, you can choose only to restore particular files and subdirectories by appending them after the command. + == Dowloading Files == If a project uses Git to manage its files, you can get a copy with: @@ -84,9 +86,9 @@ If a project uses Git to manage its files, you can get a copy with: We'll have a lot more to say about the *clone* command later. -== Keeping Up-to-date == +== The Bleeding Edge == -If a project uses Git to manage its files, and you've already downloaded a copy using *git-clone*, you can upgrade to the latest released version with: +If a project uses Git to manage its files, and you've already downloaded a copy using *git-clone*, you can upgrade to the latest version with: $ git-pull diff --git a/branch.txt b/branch.txt index 5ef663f..9196737 100644 --- a/branch.txt +++ b/branch.txt @@ -2,13 +2,13 @@ Now that you've mastered some simple Git sleights, it's time to learn some real crowd-pleasers. -External factors inevitably necessitate context switching. A severe bug manifests in the released version suddenly without warning, and must be fixed as soon as possible at all costs. The deadline for a certain feature is imminent. The guy who wrote a certain function is about to leave, so you should drop what you are doing and get him to help you understand it. +*Problem*: External factors inevitably necessitate context switching. A severe bug manifests in the released version suddenly without warning, and must be fixed as soon as possible at all costs. The deadline for a certain feature is imminent. The guy who wrote a certain function is about to leave, so you should drop what you are doing and get him to help you understand it. -Interrupting your train of thought can be detrimental to your productivity, and the slower and less convenient it is to switch contexts, the greater the loss. With centralized version control we must download a fresh working copy from the central server. Distributed systems fare much better, as we can clone the repository up to the desired version locally. +Interrupting your train of thought can be detrimental to your productivity, and the slower and less convenient it is to switch contexts, the greater the loss. With centralized version control we must download a fresh working copy from the central server. Distributed systems fare better, as we can clone the desired version locally. -But cloning still entails copying the whole working directory as well as the entire history up to the given point. Even though Git reduces the cost of this with file sharing and hard links, the project files themselves must be recreated in their entirety in the new working directory, so we may edit them. +But cloning still entails copying the whole working directory as well as the entire history up to the given point. Even though Git reduces the cost of this with file sharing and hard links, the project files themselves must be recreated in their entirety in the new working directory. -Happily, Git has a better tool for these situations that is much faster and more space-efficient than cloning: *git-branch*. +*Solution*: Git has a better tool for these situations that is much faster and more space-efficient than cloning: *git-branch*. With this magic word, the files in your directory instantly shapeshift from one version to another. This transformation can do more than merely go back or forward in history. Your files can morph from the last release to the experimental version to the current development version to your friend's version and so on. == The Boss Key == @@ -22,7 +22,7 @@ In some directory: $ git-add . $ git-commit -m "Initial commit" -So we have created a Git repository that tracks one text file containing a certain message. Now type: +We have created a Git repository that tracks one text file containing a certain message. Now type: $ git checkout -b boss # nothing seems to change after this $ echo "My boss is smarter than me" > myfile.txt diff --git a/clone.txt b/clone.txt index 4e9bab4..5c3c92b 100644 --- a/clone.txt +++ b/clone.txt @@ -37,13 +37,11 @@ Initialize a Git repository for your files: $ git add . $ git commit -m "Initial commit" -On the central server, initialize an empty Git repository with some name: - - $ GIT_DIR=proj.git git-init-db - +On the central server, initialize an empty Git repository with some name, and start the Git daemon if necessary: - $ git-daemon --detach + $ GIT_DIR=proj.git git-init-db + $ git-daemon --detach # it might already be running Some public hosts, such as [[http://repo.or.cz][repo.or.cz]], will have a different method for setting up the initially empty Git repository, such as filling in a form on a webpage. @@ -65,12 +63,6 @@ If the main server has been updated, the latest version needs to be checked out $ git commit -a $ git pull -A popular misconception is that Git is 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 good first approximation is that anything a centralized version control system can do, Git 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 of Git's features 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. - == Forking a Project == Sick of the way a project is being run? Think you could do a better job? Then on your server: @@ -101,7 +93,7 @@ The options can be written as *-l -s* instead, which I like to think of as an ac Git exploits hard links and file sharing as much as possible to create this clone. Subsequently, this clone is unsuitable as a backup. However, it's ready in a flash, and you can now work on two independent features simultaneously. For example, you can edit one clone while the other is compiling. -At any time, you can commit and pull changes the other clone. +At any time, you can commit and pull changes from the other clone. $ git-pull /the/other/clone @@ -113,7 +105,7 @@ Are you working on a project that uses some other version control system, and yo $ git add . $ git commit -m "Initial commit" -then clone it: +then clone it, at light speed: $ git-clone -l -s . /some/new/directory @@ -127,4 +119,4 @@ Then go to the new directory and run: $ git commit -a -m "description of my changes" $ git pull -On the other hand, the procedure for giving your changes to everyone else varies depending on the other version control system. The new directory contains the files with your changes. Run whatever commands of the other version control system are neeeded to upload them to the central repository. +The procedure for giving your changes to everyone else depends on the other version control system. The new directory contains the files with your changes. Run whatever commands of the other version control system are needed to upload them to the central repository. diff --git a/grandmaster.txt b/grandmaster.txt index 78856f9..2464e1a 100644 --- a/grandmaster.txt +++ b/grandmaster.txt @@ -39,17 +39,17 @@ and people can get your project via Telling Git when you've added, deleted and renamed files gets tedious. Instead, try: - $ git-ls-files -d -m -o | xargs git-update-index --add --remove + $ git-ls-files -d -m -o -z | xargs -0 git-update-index --add --remove -and Git will look at the files in the current directory and work everything out for itself. +and Git will look at the files in the current directory and work everything out for itself. The *-z* and *-0* options prevent ill side-effects from filenames containing strange characters. You might want it to ignore particular files: - $ git-ls-files -d -m -o -x *.tmp | xargs git-update-index --add --remove + $ git-ls-files -d -m -o -z -x *.tmp | xargs -0 git-update-index --add --remove If you have a big list of directories and files that should never be version controlled, type them into a separate file named "ignore" and run: - $ git-ls-files -d -m -o -X ignore | xargs git-update-index --add --remove + $ git-ls-files -d -m -o -z -X ignore | xargs -0 git-update-index --add --remove == I Stand Corrected == diff --git a/intro.txt b/intro.txt index 9aa8d4a..bf7b612 100644 --- a/intro.txt +++ b/intro.txt @@ -36,6 +36,14 @@ The new generation of version control systems, of which Git is a member, are kno This initial cloning operation can be expensive, especially if there's a long history, but it pays off in the long run. One immediate benefit is that when an old save is desired for any reason, communication with the central server is unnecessary. +=== 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 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. + == Merge Conflicts == An interesting problem arises in any type of revision control system. Suppose Alice and Bob have both independently downloaded the latest saved game. They both play the game a bit more and save. What if they both want to submit their new saves? Let's say Alice uploads first. Nothing spectacular happens, but when Bob tries to upload his save, the system realizes that his state does not chronologically follow Alice's state. -- 2.11.4.GIT