X-Git-Url: https://git.notmuchmail.org/git?a=blobdiff_plain;f=tour.mdwn;h=243737b6905b435152489d5f680c23d7de04e946;hb=7b55b40f9a1757afde7ccd40221c3537d6cd71ff;hp=6a43df9cd847aae7a5b17afbc531b3160089e372;hpb=3bad93ae6e35200f77549443103ddcc0fd2fb6d5;p=hgbook-git diff --git a/tour.mdwn b/tour.mdwn index 6a43df9..243737b 100644 --- a/tour.mdwn +++ b/tour.mdwn @@ -396,8 +396,8 @@ created: $ git log --since="2 weeks ago" --until="yesterday" -Another useful option is --max-count which, unsurprisingly, limits the -maximum number of commits to be displayed. +Another useful option is -n or --max-count which, unsurprisingly, +limits the maximum number of commits to be displayed. #### 2.4.3 More detailed information @@ -439,7 +439,7 @@ looks suspicous, so let's tak a closer look. Remember that we can name it as master~3, HEAD~3, or any prefix of its commit identifier, (such as 13ed136b): - $ git log -p --max-count=1 13ed136b + $ git log -p -n 1 13ed136b commit 13ed136b983a9c439eddeea8a1c2076cffbb685f Author: Bryan O'Sullivan Date: Tue Sep 6 13:15:43 2005 -0700 @@ -486,50 +486,56 @@ same output: ### 2.5 All about command options -Let’s take a brief break from exploring Mercurial commands to discuss +Let’s take a brief break from exploring git commands to discuss a pattern in the way that they work; you may find this useful to keep in mind as we continue our tour. -Mercurial has a consistent and straightforward approach to dealing +Git has a consistent and straightforward approach to dealing with the options that you can pass to commands. It follows the conventions for options that are common to modern Linux and Unix systems. - * Every option has a long name. For example, as we’ve already seen, - the “hg log” command accepts a --rev option. - * Most options have short names, too. Instead of --rev, we can use - -r. (The reason that some options don’t have short names is that - the options in question are rarely used.) - * Long options start with two dashes (e.g. --rev), while short - options start with one (e.g. -r). - * Option naming and usage is consistent across commands. For - example, every command that lets you specify a changeset ID or - revision number accepts both -r and --rev arguments. + * Most options have long names. For example, as we’ve already seen, + the “git log" command accepts a --max-count= option. + * Some options have short, single-character names. Often these are + aliases for long commands, (such as "-n " instead of + --max-count=), but sometimes the option exists in + short-form with no long-form equivalent, (such as -p). [XXX: It + wouldn't hurt to fix this by adding --patch, etc. right?] + * Long options start with two dashes (e.g. --max-count), while short + options start with one (e.g. -n). -In the examples throughout this book, I use short options instead of -long. This just reflects my own preference, so don’t read anything -significant into it. + * Option naming and usage is consistent across commands. For + example, every command that lets you specify a commit identifier + or range will accept the same expressions, (HEAD~3, + origin..master, 72d4f10e, etc), while any command that can be + limited by paths will accept the same expressions ("-- doc/ + some-file.c"), etc. -Most commands that print output of some kind will print more output -when passed a -v (or --verbose) option, and less when passed -q (or ---quiet). +Many commands that print output of some kind can be made more quiet by +passing the -q or --quiet options. ### 2.6 Making and reviewing changes -Now that we have a grasp of viewing history in Mercurial, let’s take a +Now that we have a grasp of viewing history in git, let’s take a look at making some changes and examining them. The first thing we’ll do is isolate our experiment in a repository of -its own. We use the “hg clone” command, but we don’t need to clone a +its own. We use the “git clone” command, but we don’t need to clone a copy of the remote repository. Since we already have a copy of it locally, we can just clone that instead. This is much faster than cloning over the network, and cloning a local repository uses less disk space in most cases, too. - $ cd .. - $ hg clone hello my-hello - 2 files updated, 0 files merged, 0 files removed, 0 files unresolved - $ cd my-hello + $ cd .. + $ git clone hello my-hello + Initialized empty Git repository in /home/cworth/src/hgbook-git/my-hello/.git/ + 0 blocks + + [XXX We say "empty" here, (presumably from the git-init part), + but shouldn't the command also report the succesful clone + which makes it non-empty? And what the heck does "0 blocks" + mean?] As an aside, it’s often good practice to keep a “pristine” copy of a remote repository around, which you can then make temporary clones of @@ -539,6 +545,17 @@ until it’s complete and you’re ready to integrate it back. Because local clones are so cheap, there’s almost no overhead to cloning and destroying repositories whenever you want. +Alternatively, you can achieve much the same effect by creating +multiple branches in a single repository, (but we won't go into detail +on how to do that in this chapter). Some people greatly appreciate +having multiple branches in a single repository rather than having +many repositories cluttering up their filesystem. Other people prefer +the ability to have working-tree changes, and intermediate build +files, etc. each isolated in a separate repository per branch. Both +modes are very well-supported by git, so it's really a matter of which +you find most appropriate at any time given your tastes and project +workflows. + In our my-hello repository, we have a file hello.c that contains the classic “hello, world” program. Let’s use the ancient and venerable sed command to edit this file so that it prints a second line of @@ -547,40 +564,46 @@ scripted example this way. Since you’re not under the same constraint, you probably won’t want to use sed; simply use your preferred text editor to do the same thing.) - $ sed -i '/printf/a∖∖tprintf("hello again!∖∖n");' hello.c + $ sed -i '/printf/a\\tprintf("hello again!\\n");' hello.c -Mercurial’s “hg status” command will tell us what Mercurial knows -about the files in the repository. +The “git status” command will tell us what git knows about the files +in the repository. - $ ls - Makefile hello.c - $ hg status - M hello.c - -The “hg status” command prints no output for some files, but a line -starting with “M” for hello.c. Unless you tell it to, “hg status” will -not print any output for files that have not been modified. - -The “M” indicates that Mercurial has noticed that we modified -hello.c. We didn’t need to inform Mercurial that we were going to -modify the file before we started, or that we had modified the file -after we were done; it was able to figure this out itself. + $ ls + hello.c Makefile + $ git status + # On branch master + # Changed but not updated: + # (use "git add ..." to update what will be committed) + # + # modified: hello.c + # + no changes added to commit (use "git add" and/or "git commit -a") + +We see that “git status” command prints a line with "modified" for +hello.c. The “git status” command will not print any output for files +that have not been modified. + +Notice that we didn’t need to inform git that we were going to modify +the file before we started, or that we had modified the file after we +were done; it was able to figure this out itself. It’s a little bit helpful to know that we’ve modified hello.c, but we might prefer to know exactly what changes we’ve made to it. To do -this, we use the “hg diff” command. +this, we use the “git diff” command. - $ hg diff - diff -r b57f9a090b62 hello.c - --- a/hello.c Tue Sep 06 15:43:07 2005 -0700 - +++ b/hello.c Sun Jun 17 18:05:50 2007 +0000 - @@ -8,5 +8,6 @@ int main(int argc, char ⋆⋆argv) - int main(int argc, char ⋆⋆argv) - { - printf("hello, world!∖"); - + printf("hello again!∖n"); - return 0; - } + $ git diff + diff --git a/hello.c b/hello.c + index 9a3ff79..6d28887 100644 + --- a/hello.c + +++ b/hello.c + @@ -8,5 +8,6 @@ + int main(int argc, char **argv) + { + printf("hello, world!\"); + + printf("hello again!\n"); + return 0; + } ### 2.7 Recording changes in a new changeset