Permalink
Browse files

Merge pull request #404 from GArik/EN

[RFC] Attempt to modernize text a bit
  • Loading branch information...
2 parents 23b06a3 + 5740030 commit 67da35bd804e656779d34810ec0d8a8ba5876965 @jnavila jnavila committed Apr 8, 2013
@@ -180,6 +180,10 @@ Here is another example `.gitignore` file:
build/
# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt
+ # ignore all .txt files in the doc/ directory
+ doc/**/*.txt
+
+A `**/` pattern is available in Git since version 1.8.2.
### Viewing Your Staged and Unstaged Changes ###
@@ -488,6 +492,26 @@ One of the more helpful options is `-p`, which shows the diff introduced in each
\ No newline at end of file
This option displays the same information but with a diff directly following each entry. This is very helpful for code review or to quickly browse what happened during a series of commits that a collaborator has added.
+
+Sometimes it's easier to review changes by words than by lines. There is a `--word-diff` option available in Git, that you can append to the `git log -p` command to get word diff instead of normal line by line diff. Word diff format is quite useless when applied to source code, but it comes in handy when applied to large text files, like books or your dissertation. Here is an example:
+
+ $ git log -U1 --word-diff
+ commit da734f4151c0bf92798edd67fb571f86ab4179e6
+ Author: Jed Hartman <jhartman@google.com>
+ Date: Tue Mar 19 18:00:35 2013 -0700
+
+ Added a missing "in" to a sentence.
+
+ diff --git a/en/01-chapter2.markdown b/en/01-chapter2.markdown
+ index 879e48c..a992ff3 100644
+ --- a/en/01-chapter2.markdown
+ +++ b/en/01-chapter2.markdown
+ @@ -553,3 +553,3 @@ You may be wondering what the difference is
+
+ This option adds a nice little ASCII graph showing your branch and merge history, which we can see {+in+} our copy of the Grit project repository:
+
+As you can see, there is no added and removed lines in this output as in a normal diff. Changes are shown inline instead. You can see the added word enclosed in `{+ +}` (removed words would have been shown as `[-removed-]`). You may also want to reduce the usual three lines context in diff output to only one line, as the context is now words, not lines. You can do this with `-U1` as we did in the example above.
+
You can also use a series of summarizing options with `git log`. For example, if you want to see some abbreviated stats for each commit, you can use the `--stat` option:
$ git log --stat
@@ -574,6 +598,7 @@ Those are only some simple output-formatting options to `git log` — there are
Option Description
-p Show the patch introduced with each commit.
+ --word-diff Show the patch in a word diff format.
--stat Show statistics for files modified in each commit.
--shortstat Display only the changed/insertions/deletions line from the --stat command.
--name-only Show the list of files modified after the commit information.
@@ -315,7 +315,7 @@ Notice the `*` character that prefixes the `master` branch: it indicates the bra
* master 7a98805 Merge branch 'iss53'
testing 782fd34 add scott to the author list in the readmes
-Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. The useful `--merged` and `--no-merged` options have been available in Git since version 1.5.6 for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch --merged`:
+Another useful option to figure out what state your branches are in is to filter this list to branches that you have or have not yet merged into the branch you’re currently on. There are useful `--merged` and `--no-merged` options available in Git for this purpose. To see which branches are already merged into the branch you’re on, you can run `git branch --merged`:
$ git branch --merged
iss53
@@ -283,8 +283,6 @@ First you need to enable the hook:
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update
-If you’re using a version of Git earlier than 1.6, the `mv` command isn’t necessary — Git started naming the hooks examples with the .sample postfix only recently.
-
What does this `post-update` hook do? It looks basically like this:
$ cat .git/hooks/post-update
@@ -993,7 +993,7 @@ Then, you e-mail that guy and yell at him.
Sometimes, developers want to get a combination of a large project’s subdirectories, depending on what team they’re on. This is common if you’re coming from CVS or Subversion, where you’ve defined a module or collection of subdirectories, and you want to keep this type of workflow.
-A good way to do this in Git is to make each of the subfolders a separate Git repository and then create superproject Git repositories that contain multiple submodules. A benefit of this approach is that you can more specifically define the relationships between the projects with tags and branches in the superprojects.
+A good way to do this in Git is to make each of the subdirectories a separate Git repository and then create superproject Git repositories that contain multiple submodules. A benefit of this approach is that you can more specifically define the relationships between the projects with tags and branches in the superprojects.
### Issues with Submodules ###
@@ -93,7 +93,7 @@ You can put patterns in your project’s `.gitignore` file to have Git not see t
#### help.autocorrect ####
-This option is available only in Git 1.6.1 and later. If you mistype a command in Git 1.6, it shows you something like this:
+This option is available only in Git 1.6.1 and later. If you mistype a command in Git, it shows you something like this:
$ git com
git: 'com' is not a git-command. See 'git --help'.
@@ -113,13 +113,13 @@ Git automatically colors most of its output if you ask it to. You can get very s
$ git config --global color.ui true
-When that value is set, Git colors its output if the output goes to a terminal. Other possible settings are false, which never colors the output, and always, which sets colors all the time, even if you’re redirecting Git commands to a file or piping them to another command. This setting was added in Git version 1.5.5; if you have an older version, you’ll have to specify all the color settings individually.
+When that value is set, Git colors its output if the output goes to a terminal. Other possible settings are false, which never colors the output, and always, which sets colors all the time, even if you’re redirecting Git commands to a file or piping them to another command.
You’ll rarely want `color.ui = always`. In most scenarios, if you want color codes in your redirected output, you can instead pass a `--color` flag to the Git command to force it to use color codes. The `color.ui = true` setting is almost always what you’ll want to use.
#### `color.*` ####
-If you want to be more specific about which commands are colored and how, or you have an older version, Git provides verb-specific coloring settings. Each of these can be set to `true`, `false`, or `always`:
+If you want to be more specific about which commands are colored and how, Git provides verb-specific coloring settings. Each of these can be set to `true`, `false`, or `always`:
color.branch
color.diff
@@ -301,13 +301,13 @@ To tell Git to treat all `pbxproj` files as binary data, add the following line
*.pbxproj -crlf -diff
-Now, Git won’t try to convert or fix CRLF issues; nor will it try to compute or print a diff for changes in this file when you run git show or git diff on your project. In the 1.6 series of Git, you can also use a macro that is provided that means `-crlf -diff`:
+Now, Git won’t try to convert or fix CRLF issues; nor will it try to compute or print a diff for changes in this file when you run `git show` or `git diff` on your project. You can also use a built-in macro `binary` that means `-crlf -diff`:
*.pbxproj binary
#### Diffing Binary Files ####
-In the 1.6 series of Git, you can use the Git attributes functionality to effectively diff binary files. You do this by telling Git how to convert your binary data to a text format that can be compared via the normal diff.
+In Git, you can use the attributes functionality to effectively diff binary files. You do this by telling Git how to convert your binary data to a text format that can be compared via the normal diff.
##### MS Word files #####
@@ -548,7 +548,7 @@ Like many other Version Control Systems, Git has a way to fire off custom script
### Installing a Hook ###
-The hooks are all stored in the `hooks` subdirectory of the Git directory. In most projects, that’s `.git/hooks`. By default, Git populates this directory with a bunch of example scripts, many of which are useful by themselves; but they also document the input values of each script. All the examples are written as shell scripts, with some Perl thrown in, but any properly named executable scripts will work fine — you can write them in Ruby or Python or what have you. For post-1.6 versions of Git, these example hook files end with .sample; you’ll need to rename them. For pre-1.6 versions of Git, the example files are named properly but are not executable.
+The hooks are all stored in the `hooks` subdirectory of the Git directory. In most projects, that’s `.git/hooks`. By default, Git populates this directory with a bunch of example scripts, many of which are useful by themselves; but they also document the input values of each script. All the examples are written as shell scripts, with some Perl thrown in, but any properly named executable scripts will work fine — you can write them in Ruby or Python or what have you. These example hook files end with .sample; you’ll need to rename them.
To enable a hook script, put a file in the `hooks` subdirectory of your Git directory that is named appropriately and is executable. From that point forward, it should be called. I’ll cover most of the major hook filenames here.
@@ -755,7 +755,7 @@ Now your users can’t push any commits with badly formed messages or with modif
#### Enforcing Fast-Forward-Only Pushes ####
-The only thing left is to enforce fast-forward-only pushes. In Git versions 1.6 or newer, you can set the `receive.denyDeletes` and `receive.denyNonFastForwards` settings. But enforcing this with a hook will work in older versions of Git, and you can modify it to do so only for certain users or whatever else you come up with later.
+The only thing left is to enforce fast-forward-only pushes. To do so, you can simply set the `receive.denyDeletes` and `receive.denyNonFastForwards` settings. But enforcing this with a hook will also work, and you can modify it to do so only for certain users or whatever else you come up with later.
The logic for checking this is to see if any commits are reachable from the older revision that aren’t reachable from the newer one. If there are none, then it was a fast-forward push; otherwise, you deny it:
View
@@ -442,7 +442,7 @@
<dia:attribute name="text">
<dia:composite type="text">
<dia:attribute name="string">
- <dia:string>#Josle#</dia:string>
+ <dia:string>#Josie#</dia:string>
</dia:attribute>
<dia:attribute name="font">
<dia:font family="Verdana" style="0" name="Courier"/>
@@ -792,7 +792,7 @@
<dia:attribute name="text">
<dia:composite type="text">
<dia:attribute name="string">
- <dia:string>#Josle#</dia:string>
+ <dia:string>#Josie#</dia:string>
</dia:attribute>
<dia:attribute name="font">
<dia:font family="Verdana" style="0" name="Courier"/>

0 comments on commit 67da35b

Please sign in to comment.