From: Junio C Hamano Date: Sun, 26 Aug 2007 22:10:26 +0000 (+0000) Subject: Autogenerated HTML docs for v1.5.3-rc6-39-g09b0 X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=8b8b0f26ab761f6032db0b27321d1f59dcbf3dd5;p=git.git Autogenerated HTML docs for v1.5.3-rc6-39-g09b0 --- diff --git a/git-add.html b/git-add.html index 8637be6ab..211ea135f 100644 --- a/git-add.html +++ b/git-add.html @@ -272,7 +272,9 @@ git-add(1) Manual Page

SYNOPSIS

-

git-add [-n] [-v] [-f] [--interactive | -i] [-u] [--refresh] [--] <file>…

+
+
git-add [-n] [-v] [-f] [--interactive | -i] [-u] [--refresh] + [--] <filepattern>…

DESCRIPTION

@@ -302,7 +304,7 @@ commit.

-<file>… +<filepattern>…

@@ -568,7 +570,7 @@ diff

diff --git a/git-add.txt b/git-add.txt index 3383aca9a..e5efbc9a4 100644 --- a/git-add.txt +++ b/git-add.txt @@ -7,7 +7,9 @@ git-add - Add file contents to the index SYNOPSIS -------- -'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--refresh] [--] ... +[verse] +'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--refresh] + [--] ... DESCRIPTION ----------- @@ -41,7 +43,7 @@ commit. OPTIONS ------- -...:: +...:: Files to add content from. Fileglobs (e.g. `*.c`) can be given to add all matching files. Also a leading directory name (e.g. `dir` to add `dir/file1` diff --git a/user-manual.html b/user-manual.html index d6f58d191..923629302 100644 --- a/user-manual.html +++ b/user-manual.html @@ -1,4 +1,4 @@ -Git User's Manual (for version 1.5.3 or newer)

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

Table of Contents

Preface
1. Repositories and Branches
How to get a git repository
How to check out a different version of a project
Understanding History: Commits
Understanding history: commits, parents, and reachability
Understanding history: History diagrams
Understanding history: What is a branch?
Manipulating branches
Examining an old version without creating a new branch
Examining branches from a remote repository
Naming branches, tags, and other references
Updating a repository with git fetch
Fetching branches from other repositories
2. Exploring git history
How to use bisect to find a regression
Naming commits
Creating tags
Browsing revisions
Generating diffs
Viewing old file versions
Examples
Counting the number of commits on a branch
Check whether two branches point at the same history
Find first tagged version including a given fix
Showing commits unique to a given branch
Creating a changelog and tarball for a software release
Finding commits referencing a file with given content
3. Developing with git
Telling git your name
Creating a new repository
How to make a commit
Creating good commit messages
Ignoring files
How to merge
Resolving a merge
Getting conflict-resolution help during a merge
Undoing a merge
Fast-forward merges
Fixing mistakes
Fixing a mistake with a new commit
Fixing a mistake by editing history
Checking out an old version of a file
Temporarily setting aside work in progress
Ensuring good performance
Ensuring reliability
Checking the repository for corruption
Recovering lost changes
4. Sharing development with others
Getting updates with git pull
Submitting patches to a project
Importing patches to a project
Public git repositories
Setting up a public repository
Exporting a git repository via the git protocol
Exporting a git repository via http
Pushing changes to a public repository
Setting up a shared repository
Allowing web browsing of a repository
Examples
Maintaining topic branches for a Linux subsystem maintainer
5. Rewriting history and maintaining patch series
Creating the perfect patch series
Keeping a patch series up to date using git-rebase
Modifying a single commit
Reordering or selecting from a patch series
Other tools
Problems with rewriting history
6. Advanced branch management
Fetching individual branches
git fetch and fast-forwards
Forcing git fetch to do non-fast-forward updates
Configuring remote branches
7. Git internals
The Object Database
Blob Object
Tree Object
Commit Object
Trust
Tag Object
The "index" aka "Current Directory Cache"
The Workflow
working directory -> index
index -> object database
object database -> index
index -> working directory
Tying it all together
Examining the data
Merging multiple trees
Merging multiple trees, continued
How git stores objects efficiently: pack files
Dangling objects
A birds-eye view of Git's source code
8. GIT Glossary
A. Git Quick Reference
Creating a new repository
Managing branches
Exploring history
Making changes
Merging
Sharing your changes
Repository maintenance
B. Notes and todo list for this manual

Preface

Git is a fast distributed revision control system.

This manual is designed to be readable by someone with basic UNIX +Git User's Manual (for version 1.5.3 or newer)

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

Table of Contents

Preface
1. Repositories and Branches
How to get a git repository
How to check out a different version of a project
Understanding History: Commits
Understanding history: commits, parents, and reachability
Understanding history: History diagrams
Understanding history: What is a branch?
Manipulating branches
Examining an old version without creating a new branch
Examining branches from a remote repository
Naming branches, tags, and other references
Updating a repository with git fetch
Fetching branches from other repositories
2. Exploring git history
How to use bisect to find a regression
Naming commits
Creating tags
Browsing revisions
Generating diffs
Viewing old file versions
Examples
Counting the number of commits on a branch
Check whether two branches point at the same history
Find first tagged version including a given fix
Showing commits unique to a given branch
Creating a changelog and tarball for a software release
Finding commits referencing a file with given content
3. Developing with git
Telling git your name
Creating a new repository
How to make a commit
Creating good commit messages
Ignoring files
How to merge
Resolving a merge
Getting conflict-resolution help during a merge
Undoing a merge
Fast-forward merges
Fixing mistakes
Fixing a mistake with a new commit
Fixing a mistake by editing history
Checking out an old version of a file
Temporarily setting aside work in progress
Ensuring good performance
Ensuring reliability
Checking the repository for corruption
Recovering lost changes
4. Sharing development with others
Getting updates with git pull
Submitting patches to a project
Importing patches to a project
Public git repositories
Setting up a public repository
Exporting a git repository via the git protocol
Exporting a git repository via http
Pushing changes to a public repository
Setting up a shared repository
Allowing web browsing of a repository
Examples
Maintaining topic branches for a Linux subsystem maintainer
5. Rewriting history and maintaining patch series
Creating the perfect patch series
Keeping a patch series up to date using git-rebase
Modifying a single commit
Reordering or selecting from a patch series
Other tools
Problems with rewriting history
6. Advanced branch management
Fetching individual branches
git fetch and fast-forwards
Forcing git fetch to do non-fast-forward updates
Configuring remote branches
7. Git internals
The Object Database
Blob Object
Tree Object
Commit Object
Trust
Tag Object
The "index" aka "Current Directory Cache"
The Workflow
working directory -> index
index -> object database
object database -> index
index -> working directory
Tying it all together
Examining the data
Merging multiple trees
Merging multiple trees, continued
How git stores objects efficiently: pack files
Dangling objects
A birds-eye view of Git's source code
8. GIT Glossary
A. Git Quick Reference
Creating a new repository
Managing branches
Exploring history
Making changes
Merging
Sharing your changes
Repository maintenance
B. Notes and todo list for this manual

Preface

Git is a fast distributed revision control system.

This manual is designed to be readable by someone with basic UNIX command-line skills, but no previous knowledge of git.

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 @@ -7,10 +7,9 @@ regressions, and so on.

People needing to do actual development will also pages. For a command such as "git clone", just use

$ man git-clone

See also Appendix A, Git Quick Reference for a brief overview of git commands, without any explanation.

Finally, see Appendix B, Notes and todo list for this manual for ways that you can help make this manual more complete.

Chapter 1. Repositories and Branches

Table of Contents

How to get a git repository
How to check out a different version of a project
Understanding History: Commits
Understanding history: commits, parents, and reachability
Understanding history: History diagrams
Understanding history: What is a branch?
Manipulating branches
Examining an old version without creating a new branch
Examining branches from a remote repository
Naming branches, tags, and other references
Updating a repository with git fetch
Fetching branches from other repositories

How to get a git repository

It will be useful to have a git repository to experiment with as you -read this manual.

The best way to get one is by using the git-clone(1) command -to download a copy of an existing repository for a project that you -are interested in. If you don't already have a project in mind, here -are some interesting examples:

        # git itself (approx. 10MB download):
+read this manual.

The best way to get one is by using the git-clone(1) command to +download a copy of an existing repository. If you don't already have a +project in mind, here are some interesting examples:

        # git itself (approx. 10MB download):
$ git clone git://git.kernel.org/pub/scm/git/git.git
        # the linux kernel (approx. 150MB download):
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

The initial clone may be time-consuming for a large project, but you @@ -18,13 +17,12 @@ will only need to clone once.

The clone command creates a new directory na ("git" or "linux-2.6" in the examples above). After you cd into this directory, you will see that it contains a copy of the project files, together with a special top-level directory named ".git", which -contains all the information about the history of the project.

In most of the following, examples will be taken from one of the two -repositories above.

How to check out a different version of a project

Git is best thought of as a tool for storing the history of a -collection of files. It stores the history as a compressed -collection of interrelated snapshots (versions) of the project's -contents.

A single git repository may contain multiple branches. It keeps track +contains all the information about the history of the project.

How to check out a different version of a project

Git is best thought of as a tool for storing the history of a collection +of files. It stores the history as a compressed collection of +interrelated snapshots of the project's contents. In git each such +version is called a commit.

A single git repository may contain multiple branches. It keeps track of them by keeping a list of heads which reference the -latest version on each branch; the git-branch(1) command shows +latest commit on each branch; the git-branch(1) command shows you the list of branch heads:

$ git branch
* master

A freshly cloned repository contains a single branch head, by default named "master", with the working directory initialized to the state of @@ -53,32 +51,27 @@ with no way to find the history it used to point to; so use this command carefully.

Understanding History: Commits

Every change in the history of a project is represented by a commit. The git-show(1) command shows the most recent commit on the current branch:

$ git show
-commit 2b5f6dcce5bf94b9b119e9ed8d537098ec61c3d2
-Author: Jamal Hadi Salim <hadi@cyberus.ca>
-Date:   Sat Dec 2 22:22:25 2006 -0800
+commit 17cf781661e6d38f737f15f53ab552f1e95960d7
+Author: Linus Torvalds <torvalds@ppc970.osdl.org.(none)>
+Date:   Tue Apr 19 14:11:06 2005 -0700

-    [XFRM]: Fix aevent structuring to be more complete.
+    Remove duplicate getenv(DB_ENVIRONMENT) call

-    aevents can not uniquely identify an SA. We break the ABI with this
-    patch, but consensus is that since it is not yet utilized by any
-    (known) application then it is fine (better do it now than later).
+    Noted by Tony Luck.

-    Signed-off-by: Jamal Hadi Salim <hadi@cyberus.ca>
-    Signed-off-by: David S. Miller <davem@davemloft.net>
+diff --git a/init-db.c b/init-db.c
+index 65898fa..b002dc6 100644
+--- a/init-db.c
++++ b/init-db.c
+@@ -7,7 +7,7 @@

-diff --git a/Documentation/networking/xfrm_sync.txt b/Documentation/networking/xfrm_sync.txt
-index 8be626f..d7aac9d 100644
---- a/Documentation/networking/xfrm_sync.txt
-+++ b/Documentation/networking/xfrm_sync.txt
-@@ -47,10 +47,13 @@ aevent_id structure looks like:
+ int main(int argc, char **argv)
+ {
+-       char *sha1_dir = getenv(DB_ENVIRONMENT), *path;
++       char *sha1_dir, *path;
+        int len, i;

-    struct xfrm_aevent_id {
-              struct xfrm_usersa_id           sa_id;
-+             xfrm_address_t                  saddr;
-              __u32                           flags;
-+             __u32                           reqid;
-    };
-...

As you can see, a commit shows who made the latest change, what they +        if (mkdir(".git", 0755) < 0) {

As you can see, a commit shows who made the latest change, what they did, and why.

Every commit has a 40-hexdigit id, sometimes called the "object name" or the "SHA1 id", shown on the first line of the "git show" output. You can usually refer to a commit by a shorter name, such as a tag or a branch name, but this @@ -224,7 +217,7 @@ a new stanza:

$ cat .git/config
...

This is what causes git to track the remote's branches; you may modify or delete these configuration options by editing .git/config with a text editor. (See the "CONFIGURATION FILE" section of -git-config(1) for details.)

Chapter 2. Exploring git history

Table of Contents

How to use bisect to find a regression
Naming commits
Creating tags
Browsing revisions
Generating diffs
Viewing old file versions
Examples
Counting the number of commits on a branch
Check whether two branches point at the same history
Find first tagged version including a given fix
Showing commits unique to a given branch
Creating a changelog and tarball for a software release
Finding commits referencing a file with given content

Git is best thought of as a tool for storing the history of a +git-config(1) for details.)

Chapter 2. Exploring git history

Table of Contents

How to use bisect to find a regression
Naming commits
Creating tags
Browsing revisions
Generating diffs
Viewing old file versions
Examples
Counting the number of commits on a branch
Check whether two branches point at the same history
Find first tagged version including a given fix
Showing commits unique to a given branch
Creating a changelog and tarball for a software release
Finding commits referencing a file with given content

Git is best thought of as a tool for storing the history of a collection of files. It does this by storing compressed snapshots of the contents of a file hierarchy, together with "commits" which show the relationships between these snapshots.

Git provides extremely flexible and fast tools for exploring the @@ -385,12 +378,12 @@ echo "git diff v$stable v$new | gzip -9 > ../patch-$new.gz"
echo "git log --no-merges v$new ^v$last > ../ChangeLog-$new"
echo "git shortlog --no-merges v$new ^v$last > ../ShortLog"
echo "git diff --stat --summary -M v$last v$new > ../diffstat-$new"

and then he just cut-and-pastes the output commands after verifying that -they look OK.

Finding commits referencing a file with given content

Somebody hands you a copy of a file, and asks which commits modified a +they look OK.

Finding commits referencing a file with given content

Somebody hands you a copy of a file, and asks which commits modified a file such that it contained the given content either before or after the commit. You can find out with this:

$  git log --raw -r --abbrev=40 --pretty=oneline -- filename |
        grep -B 1 `git hash-object filename`

Figuring out why this works is left as an exercise to the (advanced) student. The git-log(1), git-diff-tree(1), and -git-hash-object(1) man pages may prove helpful.

Chapter 3. Developing with git

Table of Contents

Telling git your name
Creating a new repository
How to make a commit
Creating good commit messages
Ignoring files
How to merge
Resolving a merge
Getting conflict-resolution help during a merge
Undoing a merge
Fast-forward merges
Fixing mistakes
Fixing a mistake with a new commit
Fixing a mistake by editing history
Checking out an old version of a file
Temporarily setting aside work in progress
Ensuring good performance
Ensuring reliability
Checking the repository for corruption
Recovering lost changes

Telling git your name

Before creating any commits, you should introduce yourself to git. The +git-hash-object(1) man pages may prove helpful.

Chapter 3. Developing with git

Table of Contents

Telling git your name
Creating a new repository
How to make a commit
Creating good commit messages
Ignoring files
How to merge
Resolving a merge
Getting conflict-resolution help during a merge
Undoing a merge
Fast-forward merges
Fixing mistakes
Fixing a mistake with a new commit
Fixing a mistake by editing history
Checking out an old version of a file
Temporarily setting aside work in progress
Ensuring good performance
Ensuring reliability
Checking the repository for corruption
Recovering lost changes

Telling git your name

Before creating any commits, you should introduce yourself to git. The easiest way to do so is to make sure the following lines appear in a file named .gitconfig in your home directory:

[user]
        name = Your Name Comes Here
@@ -442,58 +435,27 @@ backup files made by your editor. Of course, not is just a matter of not calling "git add" on them. But it quickly becomes annoying to have these untracked files lying around; e.g. they make "git add ." and "git commit -a" practically useless, and they keep -showing up in the output of "git status", etc.

Git therefore provides "exclude patterns" for telling git which files to -actively ignore. Exclude patterns are thoroughly explained in the -gitignore(5) manual page, but the heart of the concept is simply -a list of files which git should ignore. Entries in the list may contain -globs to specify multiple files, or may be prefixed by "!" to -explicitly include (un-ignore) a previously excluded (ignored) file -(i.e. later exclude patterns override earlier ones). The following -example should illustrate such patterns:

# Lines starting with '#' are considered comments.
-# Ignore foo.txt.
+showing up in the output of "git status".

You can tell git to ignore certain files by creating a file called .gitignore +in the top level of your working directory, with contents such as:

# Lines starting with '#' are considered comments.
+# Ignore any file named foo.txt.
foo.txt
# Ignore (generated) html files,
*.html
# except foo.html which is maintained by hand.
!foo.html
# Ignore objects and archives.
-*.[oa]

The next question is where to put these exclude patterns so that git can -find them. Git looks for exclude patterns in the following files:

-.gitignore files in your working tree: -
- You may store multiple .gitignore files at various locations in your - working tree. Each .gitignore file is applied to the directory where - it's located, including its subdirectories. Furthermore, the - .gitignore files can be tracked like any other files in your working - tree; just do a "git add .gitignore" and commit. .gitignore is - therefore the right place to put exclude patterns that are meant to - be shared between all project participants, such as build output files - (e.g. *.o), etc. -
-.git/info/exclude in your repo: -
- Exclude patterns in this file are applied to the working tree as a - whole. Since the file is not located in your working tree, it does - not follow push/pull/clone like .gitignore can do. This is therefore - the place to put exclude patterns that are local to your copy of the - repo (i.e. not shared between project participants), such as - temporary backup files made by your editor (e.g. *~), etc. -
-The file specified by the core.excludesfile config directive: -
- By setting the core.excludesfile config directive you can tell git - where to find more exclude patterns (see git-config(1) for - more information on configuration options). This config directive - can be set in the per-repo .git/config file, in which case the - exclude patterns will apply to that repo only. Alternatively, you - can set the directive in the global ~/.gitconfig file to apply - the exclude pattern to all your git repos. As with the above - .git/info/exclude (and, indeed, with git config directives in - general), this directive does not follow push/pull/clone, but remain - local to your repo(s). -

Note

In addition to the above alternatives, there are git commands that can take -exclude patterns directly on the command line. See git-ls-files(1) -for an example of this.

How to merge

You can rejoin two diverging branches of development using +*.[oa]

See gitignore(5) for a detailed explanation of the syntax. You can +also place .gitignore files in other directories in your working tree, and they +will apply to those directories and their subdirectories. The .gitignore +files can be added to your repository like any other files (just run git add +.gitignore and git commit, as usual), which is convenient when the exclude +patterns (such as patterns matching build output files) would also make sense +for other users who clone your repository.

If you wish the exclude patterns to affect only certain repositories +(instead of every repository for a given project), you may instead put +them in a file in your repository named .git/info/exclude, or in any file +specified by the core.excludesfile configuration variable. Some git +commands can also take exclude patterns directly on the command line. +See gitignore(5) for the details.

How to merge

You can rejoin two diverging branches of development using git-merge(1):

$ git merge branchname

merges the development in the branch "branchname" into the current branch. If there are conflicts—for example, if the same file is modified in two different ways in the remote branch and the local @@ -719,10 +681,11 @@ leave your tree and index untouched, you may omit that option.)

Once the i resolution, instead of creating a new commit, just run

$ git am --resolved

and git will create the commit for you and continue applying the remaining patches from the mailbox.

The final result will be a series of commits, one for each patch in the original mailbox, with authorship and commit log message each -taken from the message containing each patch.

Public git repositories

Another way to submit changes to a project is to tell the maintainer of -that project to pull the changes from your repository using git-pull[1]. -In the section "Getting updates with git pull" we described this as a way to get updates from the "main" -repository, but it works just as well in the other direction.

If you and the maintainer both have accounts on the same machine, then +taken from the message containing each patch.

Public git repositories

Another way to submit changes to a project is to tell the maintainer +of that project to pull the changes from your repository using +git-pull(1). In the section "Getting updates with git pull" we described this as a way to get +updates from the "main" repository, but it works just as well in the +other direction.

If you and the maintainer both have accounts on the same machine, then you can just pull changes from each other's repositories directly; commands that accept repository URLs as arguments will also accept a local directory name:

$ git clone /path/to/repository
@@ -834,7 +797,8 @@ tree:

$ git clone git://git.kernel.org/pub/s $ cd work

Linus's tree will be stored in the remote branch named origin/master, and can be updated using git-fetch(1); you can track other public trees using git-remote(1) to set up a "remote" and -git-fetch[1] to keep them up-to-date; see Chapter 1, Repositories and Branches.

Now create the branches in which you are going to work; these start out +git-fetch(1) to keep them up-to-date; see +Chapter 1, Repositories and Branches.

Now create the branches in which you are going to work; these start out at the current tip of origin/master branch, and should be set up (using the —track option to git-branch(1)) to merge changes in from Linus by default.

$ git branch --track test origin/master
@@ -1041,9 +1005,9 @@ series of patches on top of "origin", you might do something like:

And browse through the list of patches in the mywork branch using gitk, applying them (possibly in a different order) to mywork-new using cherry-pick, and possibly modifying them as you go using commit —amend. -The git-gui[1] command may also help as it allows you to individually -select diff hunks for inclusion in the index (by right-clicking on the -diff hunk and choosing "Stage Hunk for Commit").

Another technique is to use git-format-patch to create a series of +The git-gui(1) command may also help as it allows you to +individually select diff hunks for inclusion in the index (by +right-clicking on the diff hunk and choosing "Stage Hunk for Commit").

Another technique is to use git-format-patch to create a series of patches, then reset the state to before the patches:

$ git format-patch origin
$ git reset --hard origin

Then modify, reorder, or eliminate patches as preferred before applying them again with git-am(1).

Other tools

There are numerous other tools, such as StGIT, which exist for the diff --git a/user-manual.txt b/user-manual.txt index 3d02198cc..06ab79fbd 100644 --- a/user-manual.txt +++ b/user-manual.txt @@ -42,10 +42,9 @@ How to get a git repository It will be useful to have a git repository to experiment with as you read this manual. -The best way to get one is by using the gitlink:git-clone[1] command -to download a copy of an existing repository for a project that you -are interested in. If you don't already have a project in mind, here -are some interesting examples: +The best way to get one is by using the gitlink:git-clone[1] command to +download a copy of an existing repository. If you don't already have a +project in mind, here are some interesting examples: ------------------------------------------------ # git itself (approx. 10MB download): @@ -63,21 +62,18 @@ directory, you will see that it contains a copy of the project files, together with a special top-level directory named ".git", which contains all the information about the history of the project. -In most of the following, examples will be taken from one of the two -repositories above. - [[how-to-check-out]] How to check out a different version of a project ------------------------------------------------- -Git is best thought of as a tool for storing the history of a -collection of files. It stores the history as a compressed -collection of interrelated snapshots (versions) of the project's -contents. +Git is best thought of as a tool for storing the history of a collection +of files. It stores the history as a compressed collection of +interrelated snapshots of the project's contents. In git each such +version is called a <>. A single git repository may contain multiple branches. It keeps track of them by keeping a list of <> which reference the -latest version on each branch; the gitlink:git-branch[1] command shows +latest commit on each branch; the gitlink:git-branch[1] command shows you the list of branch heads: ------------------------------------------------ @@ -149,32 +145,27 @@ current branch: ------------------------------------------------ $ git show -commit 2b5f6dcce5bf94b9b119e9ed8d537098ec61c3d2 -Author: Jamal Hadi Salim -Date: Sat Dec 2 22:22:25 2006 -0800 - - [XFRM]: Fix aevent structuring to be more complete. - - aevents can not uniquely identify an SA. We break the ABI with this - patch, but consensus is that since it is not yet utilized by any - (known) application then it is fine (better do it now than later). - - Signed-off-by: Jamal Hadi Salim - Signed-off-by: David S. Miller - -diff --git a/Documentation/networking/xfrm_sync.txt b/Documentation/networking/xfrm_sync.txt -index 8be626f..d7aac9d 100644 ---- a/Documentation/networking/xfrm_sync.txt -+++ b/Documentation/networking/xfrm_sync.txt -@@ -47,10 +47,13 @@ aevent_id structure looks like: - - struct xfrm_aevent_id { - struct xfrm_usersa_id sa_id; -+ xfrm_address_t saddr; - __u32 flags; -+ __u32 reqid; - }; -... +commit 17cf781661e6d38f737f15f53ab552f1e95960d7 +Author: Linus Torvalds +Date: Tue Apr 19 14:11:06 2005 -0700 + + Remove duplicate getenv(DB_ENVIRONMENT) call + + Noted by Tony Luck. + +diff --git a/init-db.c b/init-db.c +index 65898fa..b002dc6 100644 +--- a/init-db.c ++++ b/init-db.c +@@ -7,7 +7,7 @@ + + int main(int argc, char **argv) + { +- char *sha1_dir = getenv(DB_ENVIRONMENT), *path; ++ char *sha1_dir, *path; + int len, i; + + if (mkdir(".git", 0755) < 0) { ------------------------------------------------ As you can see, a commit shows who made the latest change, what they @@ -923,7 +914,7 @@ they look OK. [[Finding-comments-with-given-content]] Finding commits referencing a file with given content ------------------------------------------------------ +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Somebody hands you a copy of a file, and asks which commits modified a file such that it contained the given content either before or after the @@ -1105,20 +1096,14 @@ backup files made by your editor. Of course, 'not' tracking files with git is just a matter of 'not' calling "`git add`" on them. But it quickly becomes annoying to have these untracked files lying around; e.g. they make "`git add .`" and "`git commit -a`" practically useless, and they keep -showing up in the output of "`git status`", etc. +showing up in the output of "`git status`". -Git therefore provides "exclude patterns" for telling git which files to -actively ignore. Exclude patterns are thoroughly explained in the -gitlink:gitignore[5] manual page, but the heart of the concept is simply -a list of files which git should ignore. Entries in the list may contain -globs to specify multiple files, or may be prefixed by "`!`" to -explicitly include (un-ignore) a previously excluded (ignored) file -(i.e. later exclude patterns override earlier ones). The following -example should illustrate such patterns: +You can tell git to ignore certain files by creating a file called .gitignore +in the top level of your working directory, with contents such as: ------------------------------------------------- # Lines starting with '#' are considered comments. -# Ignore foo.txt. +# Ignore any file named foo.txt. foo.txt # Ignore (generated) html files, *.html @@ -1128,41 +1113,20 @@ foo.txt *.[oa] ------------------------------------------------- -The next question is where to put these exclude patterns so that git can -find them. Git looks for exclude patterns in the following files: - -`.gitignore` files in your working tree::: - You may store multiple `.gitignore` files at various locations in your - working tree. Each `.gitignore` file is applied to the directory where - it's located, including its subdirectories. Furthermore, the - `.gitignore` files can be tracked like any other files in your working - tree; just do a "`git add .gitignore`" and commit. `.gitignore` is - therefore the right place to put exclude patterns that are meant to - be shared between all project participants, such as build output files - (e.g. `\*.o`), etc. -`.git/info/exclude` in your repo::: - Exclude patterns in this file are applied to the working tree as a - whole. Since the file is not located in your working tree, it does - not follow push/pull/clone like `.gitignore` can do. This is therefore - the place to put exclude patterns that are local to your copy of the - repo (i.e. 'not' shared between project participants), such as - temporary backup files made by your editor (e.g. `\*~`), etc. -The file specified by the `core.excludesfile` config directive::: - By setting the `core.excludesfile` config directive you can tell git - where to find more exclude patterns (see gitlink:git-config[1] for - more information on configuration options). This config directive - can be set in the per-repo `.git/config` file, in which case the - exclude patterns will apply to that repo only. Alternatively, you - can set the directive in the global `~/.gitconfig` file to apply - the exclude pattern to all your git repos. As with the above - `.git/info/exclude` (and, indeed, with git config directives in - general), this directive does not follow push/pull/clone, but remain - local to your repo(s). - -[NOTE] -In addition to the above alternatives, there are git commands that can take -exclude patterns directly on the command line. See gitlink:git-ls-files[1] -for an example of this. +See gitlink:gitignore[5] for a detailed explanation of the syntax. You can +also place .gitignore files in other directories in your working tree, and they +will apply to those directories and their subdirectories. The `.gitignore` +files can be added to your repository like any other files (just run `git add +.gitignore` and `git commit`, as usual), which is convenient when the exclude +patterns (such as patterns matching build output files) would also make sense +for other users who clone your repository. + +If you wish the exclude patterns to affect only certain repositories +(instead of every repository for a given project), you may instead put +them in a file in your repository named .git/info/exclude, or in any file +specified by the `core.excludesfile` configuration variable. Some git +commands can also take exclude patterns directly on the command line. +See gitlink:gitignore[5] for the details. [[how-to-merge]] How to merge @@ -1796,11 +1760,12 @@ taken from the message containing each patch. Public git repositories ----------------------- -Another way to submit changes to a project is to tell the maintainer of -that project to pull the changes from your repository using git-pull[1]. -In the section "<>" we described this as a way to get updates from the "main" -repository, but it works just as well in the other direction. +Another way to submit changes to a project is to tell the maintainer +of that project to pull the changes from your repository using +gitlink:git-pull[1]. In the section "<>" we described this as a way to get +updates from the "main" repository, but it works just as well in the +other direction. If you and the maintainer both have accounts on the same machine, then you can just pull changes from each other's repositories directly; @@ -2057,7 +2022,8 @@ $ cd work Linus's tree will be stored in the remote branch named origin/master, and can be updated using gitlink:git-fetch[1]; you can track other public trees using gitlink:git-remote[1] to set up a "remote" and -git-fetch[1] to keep them up-to-date; see <>. +gitlink:git-fetch[1] to keep them up-to-date; see +<>. Now create the branches in which you are going to work; these start out at the current tip of origin/master branch, and should be set up (using @@ -2512,9 +2478,9 @@ $ gitk origin..mywork & And browse through the list of patches in the mywork branch using gitk, applying them (possibly in a different order) to mywork-new using cherry-pick, and possibly modifying them as you go using commit --amend. -The git-gui[1] command may also help as it allows you to individually -select diff hunks for inclusion in the index (by right-clicking on the -diff hunk and choosing "Stage Hunk for Commit"). +The gitlink:git-gui[1] command may also help as it allows you to +individually select diff hunks for inclusion in the index (by +right-clicking on the diff hunk and choosing "Stage Hunk for Commit"). Another technique is to use git-format-patch to create a series of patches, then reset the state to before the patches: