Git User's Manual (for version 1.5.3 or newer)

ChapterÂ 1, Repositories and Branches and ChapterÂ 2, Exploring git history explain how to fetch and study a project using gitâread these chapters to learn how to build and test a particular version of a software project, search for @@ -255,7 +255,7 @@ point is just a suggestion, and you're free to try a different version if you think it would be a good idea. For example, occasionally you may land on a commit that broke something unrelated; run

$Â gitÂ bisectÂ visualize

which will run gitk and label the commit it chose with a marker that -says "bisect". Chose a safe-looking commit nearby, note its commit +says "bisect". Choose a safe-looking commit nearby, note its commit id, and check it out with:

$Â gitÂ resetÂ --hardÂ fb47ddb2db...

then test, run "bisect good" or "bisect bad" as appropriate, and continue.

Naming commits

We have seen several ways of naming commits already:

40-hexdigit object name @@ -775,8 +775,8 @@ way to publish a work-in-progress patch series, and it is an acceptable compromise as long as you warn other developers that this is how you intend to manage the branch.
It's also possible for a push to fail in this way when other people have the right to push to the same repository. In that case, the correct -solution is to retry the push after first updating your work by either a -pull or a fetch followed by a rebase; see the +solution is to retry the push after first updating your work: either by a +pull, or by a fetch followed by a rebase; see the next section and gitcvs-migration(7) for more.

Setting up a shared repository

Another way to collaborate is by using a model similar to that commonly used in CVS, where several developers with special rights @@ -1162,7 +1162,7 @@ SHA1 calculation.)

There are four different types of objects: "blob", "tre "tag".

A "blob" object is used to store file data.
-A "tree" object is an object that ties one or more +A "tree" object ties one or more "blob" objects into a directory structure. In addition, a tree object can refer to other tree objects, thus creating a directory hierarchy.
@@ -1272,7 +1272,7 @@ sending out a single email that tells the people the name (SHA1 hash) of the top commit, and digitally sign that email using something like GPG/PGP.
To assist in this, git also provides the tag objectâ¦

Tag Object

A tag object contains an object, object type, tag name, the name of the person ("tagger") who created the tag, and a message, which may contain -a signature, as can be seen using the git-cat-file(1):

$Â gitÂ cat-fileÂ tagÂ v1.5.0
+a signature, as can be seen using git-cat-file(1):

$Â gitÂ cat-fileÂ tagÂ v1.5.0
objectÂ 437b1b20df4b356c9342dac8d38849f24ef44f27
typeÂ commit
tagÂ v1.5.0
@@ -1722,11 +1722,11 @@ $Â gitÂ merge-fileÂ hello.c~2Â hello.c~1Â hello.c~3

This would leave with conflict markers if there are conflicts. After verifying the merge result makes sense, you can tell git what the final merge result for this file is by:

$Â mvÂ -fÂ hello.c~2Â hello.c
-$Â gitÂ update-indexÂ hello.c

When a path is in unmerged state, running git-update-index for +$Â gitÂ update-indexÂ hello.c

When a path is in the "unmerged" state, running git-update-index for that path tells git to mark the path resolved.

The above is the description of a git merge at the lowest level, to help you understand what conceptually happens under the hood. -In practice, nobody, not even git itself, uses three git-cat-file -for this. There is git-merge-index program that extracts the +In practice, nobody, not even git itself, runs git-cat-file three times +for this. There is a git-merge-index program that extracts the stages to temporary files and calls a "merge" script on it:

$Â gitÂ merge-indexÂ git-merge-one-fileÂ hello.c

and that is what higher level git-merge -s resolve is implemented with.

ChapterÂ 10.Â Hacking git

Table of Contents

Object storage format
A birds-eye view of Git's source code

This chapter covers internal details of the git implementation which probably only git developers need to understand.

Object storage format

All objects have a statically determined "type" which identifies the format of the object (i.e. how it is used, and how it can refer to other @@ -1753,7 +1753,7 @@ source code. This section gives you a little guidance to show where to start.

A good place to start is with the contents of the initial commit, with:

$Â gitÂ checkoutÂ e83c5163

The initial revision lays the foundation for almost everything git has today, but is small enough to read in one sitting.

Note that terminology has changed since that revision. For example, the README in that revision uses the word "changeset" to describe what we -now call a commit.

Also, we do not call it "cache" any more, but "index", however, the +now call a commit.

Also, we do not call it "cache" any more, but rather "index"; however, the file is still called cache.h. Remark: Not much reason to change it now, especially since there is no good single name for it anyway, because it is basically the header file which is included by all of Git's C sources.

If you grasp the ideas in that initial commit, you should check out a diff --git a/user-manual.txt b/user-manual.txt index 01c1af6b6..92d400753 100644 --- a/user-manual.txt +++ b/user-manual.txt @@ -518,7 +518,7 @@ $ git bisect visualize ------------------------------------------------- which will run gitk and label the commit it chose with a marker that -says "bisect". Chose a safe-looking commit nearby, note its commit +says "bisect". Choose a safe-looking commit nearby, note its commit id, and check it out with: ------------------------------------------------- @@ -1988,8 +1988,8 @@ intend to manage the branch. It's also possible for a push to fail in this way when other people have the right to push to the same repository. In that case, the correct -solution is to retry the push after first updating your work by either a -pull or a fetch followed by a rebase; see the +solution is to retry the push after first updating your work: either by a +pull, or by a fetch followed by a rebase; see the <> and linkgit:gitcvs-migration[7] for more. @@ -2861,7 +2861,7 @@ There are four different types of objects: "blob", "tree", "commit", and "tag". - A <> is used to store file data. -- A <> is an object that ties one or more +- A <> ties one or more "blob" objects into a directory structure. In addition, a tree object can refer to other tree objects, thus creating a directory hierarchy. - A <> ties such directory hierarchies @@ -3036,7 +3036,7 @@ Tag Object A tag object contains an object, object type, tag name, the name of the person ("tagger") who created the tag, and a message, which may contain -a signature, as can be seen using the linkgit:git-cat-file[1]: +a signature, as can be seen using linkgit:git-cat-file[1]: ------------------------------------------------ $ git cat-file tag v1.5.0 @@ -3986,13 +3986,13 @@ $ mv -f hello.c~2 hello.c $ git update-index hello.c ------------------------------------------------- -When a path is in unmerged state, running `git-update-index` for +When a path is in the "unmerged" state, running `git-update-index` for that path tells git to mark the path resolved. The above is the description of a git merge at the lowest level, to help you understand what conceptually happens under the hood. -In practice, nobody, not even git itself, uses three `git-cat-file` -for this. There is `git-merge-index` program that extracts the +In practice, nobody, not even git itself, runs `git-cat-file` three times +for this. There is a `git-merge-index` program that extracts the stages to temporary files and calls a "merge" script on it: ------------------------------------------------- @@ -4061,7 +4061,7 @@ Note that terminology has changed since that revision. For example, the README in that revision uses the word "changeset" to describe what we now call a <>. -Also, we do not call it "cache" any more, but "index", however, the +Also, we do not call it "cache" any more, but rather "index"; however, the file is still called `cache.h`. Remark: Not much reason to change it now, especially since there is no good single name for it anyway, because it is basically _the_ header file which is included by _all_ of Git's C sources. -- 2.26.2

SEE ALSO

SEE ALSO

GIT

SYNOPSIS

DESCRIPTION

DESCRIPTION

SEE ALSO

SEE ALSO

GIT

GIT

Git User's Manual (for version 1.5.3 or newer)

Preface

Git User's Manual (for version 1.5.3 or newer)

Preface

Naming commits

Setting up a shared repository

Tag Object

ChapterÂ 10.Â Hacking git

Object storage format