From 6c6760d75a228ca5afadbb21307e55486437ea0f Mon Sep 17 00:00:00 2001 From: Ben Lynn Date: Sun, 28 Mar 2010 18:36:38 -0700 Subject: [PATCH] Minor tweaks. --- en/branch.txt | 3 ++- en/clone.txt | 37 ++++++++++++++++++++++++------------- en/multiplayer.txt | 2 +- en/secrets.txt | 23 +++++++---------------- 4 files changed, 34 insertions(+), 31 deletions(-) diff --git a/en/branch.txt b/en/branch.txt index dde53ff..2c9a42a 100644 --- a/en/branch.txt +++ b/en/branch.txt @@ -166,7 +166,8 @@ It's easy to extend this trick for any number of parts. It's also easy to branch off retroactively: suppose you belatedly realize you should have created a branch 7 commits ago. Then type: - $ git branch -m master part2 # Rename "master" branch to "part2". + $ git branch -m master part2 + $ # Rename "master" branch to "part2". $ git checkout HEAD~7 -b master The `master` branch now contains just Part I, and the `part2` branch contains diff --git a/en/clone.txt b/en/clone.txt index 078ce93..a81f976 100644 --- a/en/clone.txt +++ b/en/clone.txt @@ -1,12 +1,12 @@ == Cloning Around == -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 older version control systems, checkout is the standard operation to get files. You retrieve a bunch of files in a particular 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 mirror the central server. Anything the main repository can do, you can do. === Sync Computers === -I can tolerate making tarballs or using *rsync* for backups and basic syncing. But sometimes I edit on my laptop, other times on my desktop, and the two may not have talked to each other in between. This situation drove me to learn Git in the first place. +I can tolerate making tarballs or using *rsync* for backups and basic syncing. But sometimes I edit on my laptop, other times on my desktop, and the two may not have talked to each other in between. Initialize a Git repository and commit your files on one machine. Then on the other: @@ -32,7 +32,7 @@ On the central server, initialize a 'bare repository' in some directory: $ mkdir proj.git $ cd proj.git $ git init --bare - $ # one-liner alternative: GIT_DIR=proj.git git init + $ # one-line variant: GIT_DIR=proj.git git init Start the Git daemon if necessary: @@ -45,8 +45,6 @@ empty Git repository. Typically one fills in a form on a webpage. $ git push git://central.server/path/to/proj.git HEAD -The bare repository is so named because it contains no working directory and exposes files that are hidden away in the `.git` subdirectory of a normal Git repository. In other words, the central server maintains the history of your project, and never carries a snapshot of any given version. - To check out the source, a developer types: $ git clone git://central.server/path/to/proj.git @@ -71,15 +69,28 @@ If the main server has new changes due to activity by other developers, the push fails, and the developer should pull the latest version, resolve any merge conflicts, then try again. +=== Bare repositories === + +A bare repository is so named because it has no working directory; it only contains files that are normally hidden away in the `.git` subdirectory. In other words, it maintains the history of a project, and never holds a snapshot of any given version. + +A bare repository plays a role similar to that of the main server in a +centralized version control system: the home of your project. Developers clone +your project from it, and push the latest official changes to it. Typically it +resides on a server that does little else but disseminate data. Development +occurs in the clones, so the home repository can do without a working +directory. + +Many Git commands fail on bare repositories unless the `GIT_DIR` environment variable is set to the repository path, or the `--bare` option is supplied. + === Push versus pull === -A push is more convenient than a pull in the above example. Firstly, pull fails -on bare repositories (you must 'fetch' instead; we discuss this in a later -chapter). But even if we kept a normal repository on the central server, -pulling into it is still cumbersome. Each time, we would have to login to the -server first, and give the pull command the network address of the machine -we're pulling from. Firewalls may interfere, and we might not even have shell -access to the server. +Why did we introduce the push command, rather than rely on the familiar pull +command? Firstly, pulling fails on bare repositories: instead you must 'fetch', +a command we later discuss. But even if we kept a normal repository on the +central server, pulling into it would still be cumbersome. We would have to +login to the server first, and give the pull command the network address of the +machine we're pulling from. Firewalls may interfere, and what if we have no +shell access to the server in the first place? However, apart from this case, we discourage pushing into a repository, because confusion can ensue when the destination has a working directory. @@ -91,7 +102,7 @@ Sick of the way a project is being run? Think you could do a better job? Then on $ git clone git://main.server/path/to/files -Next tell everyone about your fork of the project at your server. +Next, tell everyone about your fork of the project at your server. At any later time, you can merge in the changes from the original project with: diff --git a/en/multiplayer.txt b/en/multiplayer.txt index bcce8e2..aafd2ec 100644 --- a/en/multiplayer.txt +++ b/en/multiplayer.txt @@ -136,7 +136,7 @@ change or delete this nickname but there is usually no reason for doing so. If the original repository moves, we can update the URL via: - $ git config remote.origin.url git://example.com/new.git + $ git config remote.origin.url git://new.url/proj.git The +branch.master.merge+ option specifies the default remote branch in a *git pull*. During the initial clone, it is set to the current branch of the diff --git a/en/secrets.txt b/en/secrets.txt index 7928b0c..38712db 100644 --- a/en/secrets.txt +++ b/en/secrets.txt @@ -6,11 +6,9 @@ We take a peek under the hood and explain how Git performs its miracles. I will How can Git be so unobtrusive? Aside from occasional commits and merges, you can work as if you were unaware that version control exists. That is, until you need it, and that's when you're glad Git was watching over you the whole time. -Other version control systems don't let you forget about them. Permissions of files may be read-only unless you explicitly tell the server which files you intend to edit. The central server might be keeping track of who's checked out which code, and when. When the network goes down, you'll soon suffer. Developers constantly struggle with virtual red tape and bureaucracy. +Other version control systems force you to constantly struggle with red tape and bureaucracy. Permissions of files may be read-only unless you explicitly tell a central server which files you intend to edit. The most basic commands may slow to a crawl as the number of users increases. Work grinds to a halt when the network or the central server goes down. -The secret is the `.git` directory in your working directory. Git keeps the history of your project here. The initial ``.'' stops it showing up in `ls` listings. Except when you're pushing and pulling changes, all version control operations operate within this directory. - -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. +In contrast, Git simply keeps the history of your project in the `.git` directory in your working directory. This is your own copy of the history, so you can stay offline until you want to communicate with others. You have total control over the fate of your files because Git can easily recreate a saved state from `.git` at any time. === Integrity === @@ -42,13 +40,6 @@ The index can be thought of as a staging area because the add command puts files into Git's database and updates the index accordingly, while the commit command, without options, creates a commit based on the state of the index. -=== 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. - -Most Git commands expect the Git index to live in `.git`, and will fail on these bare repositories. Fix this by setting the `GIT_DIR` environment variable to the path of the bare repository, or running Git within the directory itself with the `--bare` option. - === Git's Origins === This http://lkml.org/lkml/2005/4/6/121[Linux Kernel Mailing List post] describes the chain of events that led to Git. The entire thread is a fascinating archaeological site for Git historians. @@ -56,12 +47,12 @@ This http://lkml.org/lkml/2005/4/6/121[Linux Kernel Mailing List post] describes === The Object Database === Every version of your data is kept in the 'object database', which lives in the -subdirectory `.git/objects`. The other residents of `.git` store lesser data -such as the index, branch names, tags, configuration files, logs, the current +subdirectory `.git/objects`; the other residents of `.git/` hold lesser data: +the index, branch names, tags, configuration options, logs, the current location of the head commit, and so on. The object database is elementary yet -elegant, and the secret to Git's power. +elegant, and the source of Git's power. -Each file within `.git/objects` is an `object`. There are 3 kinds of objects +Each file within `.git/objects` is an 'object'. There are 3 kinds of objects that concern us: 'blob' objects, 'tree' objects, and 'commit' objects. === Blobs === @@ -193,7 +184,7 @@ will always contain at least one line identifying a parent commit. === Indistinguishable From Magic === -Git's secrets seem too simple. It looks like you could mix together a few shell scripts and add a dash of C code to cook it up in a matter of hours: a melange of basic filesystem operations, SHA1 hashing, with lock files and fsyncs for robustness. In fact, this accurately describes the earliest versions of Git. Nonetheless, apart from ingenious packing tricks to save space, and ingenious indexing tricks to save time, we now know how Git deftly changes a filesystem into a database perfect for version control. +Git's secrets seem too simple. It looks like you could mix together a few shell scripts and add a dash of C code to cook it up in a matter of hours: a melange of basic filesystem operations and SHA1 hashing, garnished with lock files and fsyncs for robustness. In fact, this accurately describes the earliest versions of Git. Nonetheless, apart from ingenious packing tricks to save space, and ingenious indexing tricks to save time, we now know how Git deftly changes a filesystem into a database perfect for version control. For example, if any file within the object database is corrupted by a disk error, then its hash will no longer match, alerting us to the problem. By -- 2.11.4.GIT