Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed several typos #22

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
8 changes: 4 additions & 4 deletions text/14_Interactive_Rebasing/0_ Interactive_Rebasing.markdown
@@ -1,7 +1,7 @@
## Interactive Rebasing ## ## Interactive Rebasing ##


You can also rebase interactively. This is often used to re-write your You can also rebase interactively. This is often used to re-write your
own commit objects before pusing them somewhere. It is an easy way to own commit objects before pushing them somewhere. It is an easy way to
split, merge or re-order commits before sharing them with others. You split, merge or re-order commits before sharing them with others. You
can also use it to clean up commits you've pulled from someone when can also use it to clean up commits you've pulled from someone when
applying them locally. applying them locally.
Expand All @@ -17,7 +17,7 @@ since the last time you have pushed (or merged from the origin repository).


To see what commits those are beforehand, you can run log this way: To see what commits those are beforehand, you can run log this way:


$ git log github/master.. $ git log origin/master..


Once you run the 'rebase -i' command, you will be thrown into your editor Once you run the 'rebase -i' command, you will be thrown into your editor
of choice with something that looks like this: of choice with something that looks like this:
Expand Down Expand Up @@ -88,7 +88,7 @@ Then you will have to create a single commit message from this:


This reverts commit fc62e5543b195f18391886b9f663d5a7eca38e84. This reverts commit fc62e5543b195f18391886b9f663d5a7eca38e84.


Once you have edited that down into once commit message and exit the editor, Once you have edited that down into one single commit message and exit the editor,
the commit will be saved with your new message. the commit will be saved with your new message.


If 'edit' is specified, it will do the same thing, but then pause before If 'edit' is specified, it will do the same thing, but then pause before
Expand All @@ -106,7 +106,7 @@ that commit:


And then when you get to the command line, you revert that commit and create And then when you get to the command line, you revert that commit and create
two (or more) new ones. Lets say 21d80a5 modified two files, file1 and file2, two (or more) new ones. Lets say 21d80a5 modified two files, file1 and file2,
and you wanted to split them into seperate commits. You could do this after and you wanted to split them into separate commits. You could do this after
the rebase dropped you to the command line : the rebase dropped you to the command line :


$ git reset HEAD^ $ git reset HEAD^
Expand Down
2 changes: 1 addition & 1 deletion text/15_Interactive_Adding/0_ Interactive_Adding.markdown
Expand Up @@ -82,7 +82,7 @@ If you type '5' or 'p' in the menu, git will show you your diff patch by patch
(or hunk by hunk) and ask if you want to stage each one. That way you can (or hunk by hunk) and ask if you want to stage each one. That way you can
actually stage for a commit a part of a file edit. If you've edited a file actually stage for a commit a part of a file edit. If you've edited a file
and want to only commit part of it and not an unfinished part, or commit and want to only commit part of it and not an unfinished part, or commit
documentation or whitespace changes seperate from substantive changes, you can documentation or whitespace changes separate from substantive changes, you can
use 'git add -i' to do so relatively easily. use 'git add -i' to do so relatively easily.


Here I've staged some changes to the book_index_template.html file, but not all Here I've staged some changes to the book_index_template.html file, but not all
Expand Down
Expand Up @@ -24,7 +24,7 @@ however they have ssh authentication setup.


### Multiple User Access using Gitosis ### ### Multiple User Access using Gitosis ###


If you don't want to setup seperate accounts for every user, you can use If you don't want to setup separate accounts for every user, you can use
a tool called Gitosis. In gitosis, there is an authorized_keys file that a tool called Gitosis. In gitosis, there is an authorized_keys file that
contains the public keys of everyone authorized to access the repository, contains the public keys of everyone authorized to access the repository,
and then everyone uses the 'git' user to do pushes and pulls. and then everyone uses the 'git' user to do pushes and pulls.
Expand Down
Expand Up @@ -11,7 +11,7 @@ packed objects.
### Loose Objects ### ### Loose Objects ###


Loose objects are the simpler format. It is simply the compressed data stored Loose objects are the simpler format. It is simply the compressed data stored
in a single file on disk. Every object written to a seperate file. in a single file on disk. Every object written to a separate file.


If the sha of your object is <code>ab04d884140f7b0cf8bbf86d6883869f16a46f65</code>, If the sha of your object is <code>ab04d884140f7b0cf8bbf86d6883869f16a46f65</code>,
then the file will be stored in the following path: then the file will be stored in the following path:
Expand Down Expand Up @@ -49,7 +49,7 @@ implementation of object storage:
### Packed Objects ### ### Packed Objects ###


The other format for object storage is the packfile. Since Git stores each The other format for object storage is the packfile. Since Git stores each
version of each file as a seperate object, it can get pretty inefficient. version of each file as a separate object, it can get pretty inefficient.
Imagine having a file several thousand lines long and changing a single line. Imagine having a file several thousand lines long and changing a single line.
Git will store the second file in it's entirety, which is a great big waste Git will store the second file in it's entirety, which is a great big waste
of space. of space.
Expand Down
2 changes: 1 addition & 1 deletion text/52_The_Packfile/0_The_Packfile.markdown
Expand Up @@ -29,7 +29,7 @@ with a given byte can be found to avoid 8 iterations of the binary
search). search).


In version 1, the offsets and shas are in the same space, where in version two, In version 1, the offsets and shas are in the same space, where in version two,
there are seperate tables there are separate tables
for the shas, crc checksums and offsets. At the end of both files are for the shas, crc checksums and offsets. At the end of both files are
checksum shas for both the index file and the packfile it references. checksum shas for both the index file and the packfile it references.


Expand Down