From 13436e57ac9b207ad2781a619d80b18453f85a75 Mon Sep 17 00:00:00 2001 From: Ben Lynn Date: Thu, 6 Nov 2008 16:43:59 -0800 Subject: [PATCH] Minor edits. --- basic.txt | 6 ++++-- branch.txt | 26 ++++++++++++++------------ clone.txt | 6 +++--- intro.txt | 6 ++---- 4 files changed, 23 insertions(+), 21 deletions(-) diff --git a/basic.txt b/basic.txt index 8195403..4c4262b 100644 --- a/basic.txt +++ b/basic.txt @@ -1,6 +1,8 @@ == Basic Tricks == -Rather than diving into a sea of Git commands, use these elementary examples to get your feet wet. Despite their simplicity, each of them are useful. +Rather than diving into a sea of Git commands, use these elementary examples to +get your feet wet. Despite their simplicity, each of them are useful. In fact, +for many purposes you can get by with a handful of basic commands. === Saving State === @@ -53,7 +55,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 <>. For now, just remember that +This alternate reality is called a 'branch', and <>. For now, just remember that $ git checkout master diff --git a/branch.txt b/branch.txt index 5d66d3b..1151cbb 100644 --- a/branch.txt +++ b/branch.txt @@ -145,20 +145,21 @@ See *git help branch*. === Temporary Branches === After a while you may realize that you are creating short-lived branches -frequently for the same reasons. Perhaps you feel almost every second branch -you create is only so you can save the current state somewhere while you -briefly perform some operation on the previous state, such as fix a -high-priority bug. +frequently for the same reasons. Perhaps it seems every other time you create a +branch is just so you can save the current state while you briefly perform some +operation on the last saved state, such as fixing a high-priority bug. -Scripting can relieve the tedium of creating, deleting and checking out -temporary branches and commits, but there's an even simpler way: +It's analogous to changing the TV channel temporarily to see what else is on, +but instead of pushing a couple of buttons, you have to create, check out and +delete temporary branches and commits. Luckily, Git has a feature that +is as convenient as a TV remote control: $ git stash This command saves the current state in a temporary location (a 'stash') and -restores the previous state, so your working directory appears exactly as it -was before you started editing. You can fix bugs, pull in upstream changes, and -so on. When you want to go back to the stashed state, type +restores the previous state. Your working directory appears exactly as it was +before you started editing, and you can fix bugs, pull in upstream changes, and +so on. When you want to go back to the stashed state, type: $ git stash apply # You may need to resolve some conflicts. @@ -183,8 +184,9 @@ Most importantly, these operations will be slower to some degree, usually to the I experienced these phenomena first-hand. Git was the first version control system I used, and I grew accustomed to it, taking many features for granted. I did not know what centralized systems were like, and assumed they were similar. Later, I was forced to use one. -Often I have a flaky internet connection. This matters little with Git, but makes development unbearable with a centralized system. - -Additionally, I found myself conditioned to avoid certain commands because of the latencies involved, which ultimately prevented me from following the work flow I wanted. +Often I have a flaky internet connection. This matters little with Git, but +makes development unbearable with a centralized system. Additionally, I found +myself conditioned to avoid certain commands because of the latencies involved, +which ultimately prevented me from following the work flow I wanted. When I had to run a slow command, the interruption to my train of thought dealt a disproportionate amount of damage. While waiting for server communcation to complete, I'd do something else to pass the time, such as check email or write documentation. By the time I returned to the original task, the command had already finished long ago. I would then spend a long time trying to remember what I was doing. diff --git a/clone.txt b/clone.txt index f97260a..d7f3b4a 100644 --- a/clone.txt +++ b/clone.txt @@ -1,8 +1,8 @@ == Cloning Around == -In older version control systems, checkout is the standard operation to get files. You checkout a bunch of files in the requested saved state. +In older version control systems, checkout is the standard operation to get files. You retrieve a bunch of files in the requested saved state. -In Git and other distributed version control systems, cloning is the standard operation. To get files you create a clone of the entire repository. In other words, you practically create a mirror of the central server. Anything the main repository can do, you can do. +In Git and other distributed version control systems, cloning is the standard operation. To get files you create a clone of the entire repository. In other words, you practically mirror the central server. Anything the main repository can do, you can do. === Sync Computers === @@ -75,7 +75,7 @@ The truly paranoid should always write down the latest 20-byte SHA1 hash of the === Light-Speed Multitask === -Say you want to work on several features in parallel. Then after committing your project: +Say you want to work on several features in parallel. Then commit your project and run: $ git clone . /some/new/directory diff --git a/intro.txt b/intro.txt index 4f03210..8fcb184 100644 --- a/intro.txt +++ b/intro.txt @@ -46,11 +46,9 @@ A small project may only need a fraction of the features offered by such a syste === 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. Then when Bob tries to upload his save, the system realizes that his state does not chronologically follow Alice's state. +For this topic, our computer game analogy becomes too thinly stretched since most games never worry about this, so let us consider the case of editing a document. -Let us revert to editing a text file. Our computer game analogy becomes too thinly stretched since most games never worry about this. - -So suppose Alice has inserted a line at the beginning of a file, and Bob appends one at the end. They both upload their changes. Most systems will automatically deduce a reasonable course of action: accept and merge their changes, so both Alice's and Bob's edits are applied. +Suppose Alice has inserted a line at the beginning of a file, and Bob appends one at the end. They both upload their changes. Most systems will automatically deduce a reasonable course of action: accept and merge their changes, so both Alice's and Bob's edits are applied. Now suppose both Alice and Bob have made distinct edits to the same line. Then it is impossible to resolve the conflict without human intervention. The second person to upload is informed of a merge conflict, and they must either choose one edit over another, or revise the line entirely. -- 2.11.4.GIT