diff --git a/Documentation/Makefile b/Documentation/Makefile index 5314068d32..266af47176 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -17,7 +17,7 @@ ARTICLES += hooks ARTICLES += everyday ARTICLES += git-tools # with their own formatting rules. -SP_ARTICLES = glossary howto/revert-branch-rebase +SP_ARTICLES = glossary howto/revert-branch-rebase user-manual DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES)) @@ -99,6 +99,12 @@ clean: %.xml : %.txt asciidoc -b docbook -d manpage -f asciidoc.conf $< +user-manual.xml: user-manual.txt user-manual.conf + asciidoc -b docbook -d book $< + +user-manual.html: user-manual.xml + xmlto html-nochunks $< + glossary.html : glossary.txt sort_glossary.pl cat $< | \ perl sort_glossary.pl | \ diff --git a/Documentation/docbook-xsl.css b/Documentation/docbook-xsl.css new file mode 100644 index 0000000000..8821e305dd --- /dev/null +++ b/Documentation/docbook-xsl.css @@ -0,0 +1,286 @@ +/* + CSS stylesheet for XHTML produced by DocBook XSL stylesheets. + Tested with XSL stylesheets 1.61.2, 1.67.2 +*/ + +span.strong { + font-weight: bold; +} + +body blockquote { + margin-top: .75em; + line-height: 1.5; + margin-bottom: .75em; +} + +html body { + margin: 1em 5% 1em 5%; + line-height: 1.2; +} + +body div { + margin: 0; +} + +h1, h2, h3, h4, h5, h6, +div.toc p b, +div.list-of-figures p b, +div.list-of-tables p b, +div.abstract p.title +{ + color: #527bbd; + font-family: tahoma, verdana, sans-serif; +} + +div.toc p:first-child, +div.list-of-figures p:first-child, +div.list-of-tables p:first-child, +div.example p.title +{ + margin-bottom: 0.2em; +} + +body h1 { + margin: .0em 0 0 -4%; + line-height: 1.3; + border-bottom: 2px solid silver; +} + +body h2 { + margin: 0.5em 0 0 -4%; + line-height: 1.3; + border-bottom: 2px solid silver; +} + +body h3 { + margin: .8em 0 0 -3%; + line-height: 1.3; +} + +body h4 { + margin: .8em 0 0 -3%; + line-height: 1.3; +} + +body h5 { + margin: .8em 0 0 -2%; + line-height: 1.3; +} + +body h6 { + margin: .8em 0 0 -1%; + line-height: 1.3; +} + +body hr { + border: none; /* Broken on IE6 */ +} +div.footnotes hr { + border: 1px solid silver; +} + +div.navheader th, div.navheader td, div.navfooter td { + font-family: sans-serif; + font-size: 0.9em; + font-weight: bold; + color: #527bbd; +} +div.navheader img, div.navfooter img { + border-style: none; +} +div.navheader a, div.navfooter a { + font-weight: normal; +} +div.navfooter hr { + border: 1px solid silver; +} + +body td { + line-height: 1.2 +} + +body th { + line-height: 1.2; +} + +ol { + line-height: 1.2; +} + +ul, body dir, body menu { + line-height: 1.2; +} + +html { + margin: 0; + padding: 0; +} + +body h1, body h2, body h3, body h4, body h5, body h6 { + margin-left: 0 +} + +body pre { + margin: 0.5em 10% 0.5em 1em; + line-height: 1.0; + color: navy; +} + +tt.literal, code.literal { + color: navy; +} + +div.literallayout p { + padding: 0em; + margin: 0em; +} + +div.literallayout { + font-family: monospace; +# margin: 0.5em 10% 0.5em 1em; + margin: 0em; + color: navy; + border: 1px solid silver; + background: #f4f4f4; + padding: 0.5em; +} + +.programlisting, .screen { + border: 1px solid silver; + background: #f4f4f4; + margin: 0.5em 10% 0.5em 0; + padding: 0.5em 1em; +} + +div.sidebar { + background: #ffffee; + margin: 1.0em 10% 0.5em 0; + padding: 0.5em 1em; + border: 1px solid silver; +} +div.sidebar * { padding: 0; } +div.sidebar div { margin: 0; } +div.sidebar p.title { + font-family: sans-serif; + margin-top: 0.5em; + margin-bottom: 0.2em; +} + +div.bibliomixed { + margin: 0.5em 5% 0.5em 1em; +} + +div.glossary dt { + font-weight: bold; +} +div.glossary dd p { + margin-top: 0.2em; +} + +dl { + margin: .8em 0; + line-height: 1.2; +} + +dt { + margin-top: 0.5em; +} + +dt span.term { + font-style: italic; +} + +div.variablelist dd p { + margin-top: 0; +} + +div.itemizedlist li, div.orderedlist li { + margin-left: -0.8em; + margin-top: 0.5em; +} + +ul, ol { + list-style-position: outside; +} + +div.sidebar ul, div.sidebar ol { + margin-left: 2.8em; +} + +div.itemizedlist p.title, +div.orderedlist p.title, +div.variablelist p.title +{ + margin-bottom: -0.8em; +} + +div.revhistory table { + border-collapse: collapse; + border: none; +} +div.revhistory th { + border: none; + color: #527bbd; + font-family: tahoma, verdana, sans-serif; +} +div.revhistory td { + border: 1px solid silver; +} + +/* Keep TOC and index lines close together. */ +div.toc dl, div.toc dt, +div.list-of-figures dl, div.list-of-figures dt, +div.list-of-tables dl, div.list-of-tables dt, +div.indexdiv dl, div.indexdiv dt +{ + line-height: normal; + margin-top: 0; + margin-bottom: 0; +} + +/* + Table styling does not work because of overriding attributes in + generated HTML. +*/ +div.table table, +div.informaltable table +{ + margin-left: 0; + margin-right: 5%; + margin-bottom: 0.8em; +} +div.informaltable table +{ + margin-top: 0.4em +} +div.table thead, +div.table tfoot, +div.table tbody, +div.informaltable thead, +div.informaltable tfoot, +div.informaltable tbody +{ + /* No effect in IE6. */ + border-top: 2px solid #527bbd; + border-bottom: 2px solid #527bbd; +} +div.table thead, div.table tfoot, +div.informaltable thead, div.informaltable tfoot +{ + font-weight: bold; +} + +div.mediaobject img { + border: 1px solid silver; + margin-bottom: 0.8em; +} +div.figure p.title, +div.table p.title +{ + margin-top: 1em; + margin-bottom: 0.4em; +} + +@media print { + div.navheader, div.navfooter { display: none; } +} diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt index 7e90ce91bc..075c0d05ef 100644 --- a/Documentation/git-cat-file.txt +++ b/Documentation/git-cat-file.txt @@ -19,7 +19,9 @@ or '-s' is used to find the object size. OPTIONS ------- :: - The sha1 identifier of the object. + The name of the object to show. + For a more complete list of ways to spell object names, see + "SPECIFYING REVISIONS" section in gitlink:git-rev-parse[1]. -t:: Instead of the content, show the object type identified by diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt index c44a4a8004..4ea2b315d2 100644 --- a/Documentation/git-checkout.txt +++ b/Documentation/git-checkout.txt @@ -9,7 +9,7 @@ SYNOPSIS -------- [verse] 'git-checkout' [-f] [-b [-l]] [-m] [] -'git-checkout' [] ... +'git-checkout' [] ... DESCRIPTION ----------- @@ -22,11 +22,13 @@ be created. When are given, this command does *not* switch branches. It updates the named paths in the working tree from -the index file (i.e. it runs `git-checkout-index -f -u`). In +the index file (i.e. it runs `git-checkout-index -f -u`), or a +named commit. In this case, `-f` and `-b` options are meaningless and giving -either of them results in an error. argument can be -used to specify a specific tree-ish to update the index for the -given paths before updating the working tree. +either of them results in an error. argument can be +used to specify a specific tree-ish (i.e. commit, tag or tree) +to update the index for the given paths before updating the +working tree. OPTIONS diff --git a/Documentation/git.txt b/Documentation/git.txt index 7cd3467986..29ee24c34f 100644 --- a/Documentation/git.txt +++ b/Documentation/git.txt @@ -22,6 +22,9 @@ See this link:tutorial.html[tutorial] to get started, then see link:everyday.html[Everyday Git] for a useful minimum set of commands, and "man git-commandname" for documentation of each command. CVS users may also want to read link:cvs-migration.html[CVS migration]. +link:user-manual.html[Git User's Manual] is still work in +progress, but when finished hopefully it will guide a new user +in a coherent way to git enlightenment ;-). The COMMAND is either a name of a Git command (see below) or an alias as defined in the configuration file (see gitlink:git-config[1]). diff --git a/Documentation/user-manual.conf b/Documentation/user-manual.conf new file mode 100644 index 0000000000..92b01ecf71 --- /dev/null +++ b/Documentation/user-manual.conf @@ -0,0 +1,21 @@ +[titles] + underlines="__","==","--","~~","^^" + +[attributes] +caret=^ +startsb=[ +endsb=] +tilde=~ + +[gitlink-inlinemacro] +{target}{0?({0})} + +ifdef::backend-docbook[] +# "unbreak" docbook-xsl v1.68 for manpages. v1.69 works with or without this. +[listingblock] +{title} + +| + +{title#} +endif::backend-docbook[] diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt new file mode 100644 index 0000000000..b6916d11b2 --- /dev/null +++ b/Documentation/user-manual.txt @@ -0,0 +1,2959 @@ +Git User's Manual +_________________ + +This manual is designed to be readable by someone with basic unix +commandline skills, but no previous knowledge of git. + +Chapter 1 gives a brief overview of git commands, without any +explanation; you may prefer to skip to chapter 2 on a first reading. + +Chapters 2 and 3 explain how to fetch and study a project using +git--the tools you'd need to build and test a particular version of a +software project, to search for regressions, and so on. + +Chapter 4 explains how to do development with git, and chapter 5 how +to share that development with others. + +Further chapters cover more specialized topics. + +Comprehensive reference documentation is available through the man +pages. For a command such as "git clone", just use + +------------------------------------------------ +$ man git-clone +------------------------------------------------ + +Git Quick Start +=============== + +This is a quick summary of the major commands; the following chapters +will explain how these work in more detail. + +Creating a new repository +------------------------- + +From a tarball: + +----------------------------------------------- +$ tar xzf project.tar.gz +$ cd project +$ git init +Initialized empty Git repository in .git/ +$ git add . +$ git commit +----------------------------------------------- + +From a remote repository: + +----------------------------------------------- +$ git clone git://example.com/pub/project.git +$ cd project +----------------------------------------------- + +Managing branches +----------------- + +----------------------------------------------- +$ git branch # list all branches in this repo +$ git checkout test # switch working directory to branch "test" +$ git branch new # create branch "new" starting at current HEAD +$ git branch -d new # delete branch "new" +----------------------------------------------- + +Instead of basing new branch on current HEAD (the default), use: + +----------------------------------------------- +$ git branch new test # branch named "test" +$ git branch new v2.6.15 # tag named v2.6.15 +$ git branch new HEAD^ # commit before the most recent +$ git branch new HEAD^^ # commit before that +$ git branch new test~10 # ten commits before tip of branch "test" +----------------------------------------------- + +Create and switch to a new branch at the same time: + +----------------------------------------------- +$ git checkout -b new v2.6.15 +----------------------------------------------- + +Update and examine branches from the repository you cloned from: + +----------------------------------------------- +$ git fetch # update +$ git branch -r # list + origin/master + origin/next + ... +$ git branch checkout -b masterwork origin/master +----------------------------------------------- + +Fetch a branch from a different repository, and give it a new +name in your repository: + +----------------------------------------------- +$ git fetch git://example.com/project.git theirbranch:mybranch +$ git fetch git://example.com/project.git v2.6.15:mybranch +----------------------------------------------- + +Keep a list of repositories you work with regularly: + +----------------------------------------------- +$ git remote add example git://example.com/project.git +$ git remote # list remote repositories +example +origin +$ git remote show example # get details +* remote example + URL: git://example.com/project.git + Tracked remote branches + master next ... +$ git fetch example # update branches from example +$ git branch -r # list all remote branches +----------------------------------------------- + + +Exploring history +----------------- + +----------------------------------------------- +$ gitk # visualize and browse history +$ git log # list all commits +$ git log src/ # ...modifying src/ +$ git log v2.6.15..v2.6.16 # ...in v2.6.16, not in v2.6.15 +$ git log master..test # ...in branch test, not in branch master +$ git log test..master # ...in branch master, but not in test +$ git log test...master # ...in one branch, not in both +$ git log -S'foo()' # ...where difference contain "foo()" +$ git log --since="2 weeks ago" +$ git log -p # show patches as well +$ git show # most recent commit +$ git diff v2.6.15..v2.6.16 # diff between two tagged versions +$ git diff v2.6.15..HEAD # diff with current head +$ git grep "foo()" # search working directory for "foo()" +$ git grep v2.6.15 "foo()" # search old tree for "foo()" +$ git show v2.6.15:a.txt # look at old version of a.txt +----------------------------------------------- + +Search for regressions: + +----------------------------------------------- +$ git bisect start +$ git bisect bad # current version is bad +$ git bisect good v2.6.13-rc2 # last known good revision +Bisecting: 675 revisions left to test after this + # test here, then: +$ git bisect good # if this revision is good, or +$ git bisect bad # if this revision is bad. + # repeat until done. +----------------------------------------------- + +Making changes +-------------- + +Make sure git knows who to blame: + +------------------------------------------------ +$ cat >~/.gitconfig <<\EOF +[user] +name = Your Name Comes Here +email = you@yourdomain.example.com +EOF +------------------------------------------------ + +Select file contents to include in the next commit, then make the +commit: + +----------------------------------------------- +$ git add a.txt # updated file +$ git add b.txt # new file +$ git rm c.txt # old file +$ git commit +----------------------------------------------- + +Or, prepare and create the commit in one step: + +----------------------------------------------- +$ git commit d.txt # use latest content only of d.txt +$ git commit -a # use latest content of all tracked files +----------------------------------------------- + +Merging +------- + +----------------------------------------------- +$ git merge test # merge branch "test" into the current branch +$ git pull git://example.com/project.git master + # fetch and merge in remote branch +$ git pull . test # equivalent to git merge test +----------------------------------------------- + +Sharing your changes +-------------------- + +Importing or exporting patches: + +----------------------------------------------- +$ git format-patch origin..HEAD # format a patch for each commit + # in HEAD but not in origin +$ git-am mbox # import patches from the mailbox "mbox" +----------------------------------------------- + +Fetch a branch in a different git repository, then merge into the +current branch: + +----------------------------------------------- +$ git pull git://example.com/project.git theirbranch +----------------------------------------------- + +Store the fetched branch into a local branch before merging into the +current branch: + +----------------------------------------------- +$ git pull git://example.com/project.git theirbranch:mybranch +----------------------------------------------- + +After creating commits on a local branch, update the remote +branch with your commits: + +----------------------------------------------- +$ git push ssh://example.com/project.git mybranch:theirbranch +----------------------------------------------- + +When remote and local branch are both named "test": + +----------------------------------------------- +$ git push ssh://example.com/project.git test +----------------------------------------------- + +Shortcut version for a frequently used remote repository: + +----------------------------------------------- +$ git remote add example ssh://example.com/project.git +$ git push example test +----------------------------------------------- + +Repository maintenance +---------------------- + +Check for corruption: + +----------------------------------------------- +$ git fsck +----------------------------------------------- + +Recompress, remove unused cruft: + +----------------------------------------------- +$ git gc +----------------------------------------------- + +Repositories and Branches +========================= + +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: + +------------------------------------------------ + # 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 +will only need to clone once. + +The clone command creates a new directory named after the project +("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. Each branch +is a bookmark referencing a particular point in the project history. +The gitlink:git-branch[1] command shows you the list of branches: + +------------------------------------------------ +$ git branch +* master +------------------------------------------------ + +A freshly cloned repository contains a single branch, named "master", +and the working directory contains the version of the project +referred to by the master branch. + +Most projects also use tags. Tags, like branches, are references +into the project's history, and can be listed using the +gitlink:git-tag[1] command: + +------------------------------------------------ +$ git tag -l +v2.6.11 +v2.6.11-tree +v2.6.12 +v2.6.12-rc2 +v2.6.12-rc3 +v2.6.12-rc4 +v2.6.12-rc5 +v2.6.12-rc6 +v2.6.13 +... +------------------------------------------------ + +Tags are expected to always point at the same version of a project, +while branches are expected to advance as development progresses. + +Create a new branch pointing to one of these versions and check it +out using gitlink:git-checkout[1]: + +------------------------------------------------ +$ git checkout -b new v2.6.13 +------------------------------------------------ + +The working directory then reflects the contents that the project had +when it was tagged v2.6.13, and gitlink:git-branch[1] shows two +branches, with an asterisk marking the currently checked-out branch: + +------------------------------------------------ +$ git branch + master +* new +------------------------------------------------ + +If you decide that you'd rather see version 2.6.17, you can modify +the current branch to point at v2.6.17 instead, with + +------------------------------------------------ +$ git reset --hard v2.6.17 +------------------------------------------------ + +Note that if the current branch was your only reference to a +particular point in history, then resetting that branch may leave you +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 gitlink:git-show[1] command shows the most recent commit on the +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; + }; +... +------------------------------------------------ + +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 longer name can also be useful. Most +importantly, it is a globally unique name for this commit: so if you +tell somebody else the object name (for example in email), then you are +guaranteed that name will refer to the same commit in their repository +that you it does in yours (assuming their repository has that commit at +all). + +Understanding history: commits, parents, and reachability +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Every commit (except the very first commit in a project) also has a +parent commit which shows what happened before this commit. +Following the chain of parents will eventually take you back to the +beginning of the project. + +However, the commits do not form a simple list; git allows lines of +development to diverge and then reconverge, and the point where two +lines of development reconverge is called a "merge". The commit +representing a merge can therefore have more than one parent, with +each parent representing the most recent commit on one of the lines +of development leading to that point. + +The best way to see how this works is using the gitlink:gitk[1] +command; running gitk now on a git repository and looking for merge +commits will help understand how the git organizes history. + +In the following, we say that commit X is "reachable" from commit Y +if commit X is an ancestor of commit Y. Equivalently, you could say +that Y is a descendent of X, or that there is a chain of parents +leading from commit Y to commit X. + +Undestanding history: History diagrams +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +We will sometimes represent git history using diagrams like the one +below. Commits are shown as "o", and the links between them with +lines drawn with - / and \. Time goes left to right: + + o--o--o <-- Branch A + / + o--o--o <-- master + \ + o--o--o <-- Branch B + +If we need to talk about a particular commit, the character "o" may +be replaced with another letter or number. + +Understanding history: What is a branch? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Though we've been using the word "branch" to mean a kind of reference +to a particular commit, the word branch is also commonly used to +refer to the line of commits leading up to that point. In the +example above, git may think of the branch named "A" as just a +pointer to one particular commit, but we may refer informally to the +line of three commits leading up to that point as all being part of +"branch A". + +If we need to make it clear that we're just talking about the most +recent commit on the branch, we may refer to that commit as the +"head" of the branch. + +Manipulating branches +--------------------- + +Creating, deleting, and modifying branches is quick and easy; here's +a summary of the commands: + +git branch:: + list all branches +git branch :: + create a new branch named , referencing the same + point in history as the current branch +git branch :: + create a new branch named , referencing + , which may be specified any way you like, + including using a branch name or a tag name +git branch -d :: + delete the branch ; if the branch you are deleting + points to a commit which is not reachable from this branch, + this command will fail with a warning. +git branch -D :: + even if the branch points to a commit not reachable + from the current branch, you may know that that commit + is still reachable from some other branch or tag. In that + case it is safe to use this command to force git to delete + the branch. +git checkout :: + make the current branch , updating the working + directory to reflect the version referenced by +git checkout -b :: + create a new branch referencing , and + check it out. + +It is also useful to know that the special symbol "HEAD" can always +be used to refer to the current branch. + +Examining branches from a remote repository +------------------------------------------- + +The "master" branch that was created at the time you cloned is a copy +of the HEAD in the repository that you cloned from. That repository +may also have had other branches, though, and your local repository +keeps branches which track each of those remote branches, which you +can view using the "-r" option to gitlink:git-branch[1]: + +------------------------------------------------ +$ git branch -r + origin/HEAD + origin/html + origin/maint + origin/man + origin/master + origin/next + origin/pu + origin/todo +------------------------------------------------ + +You cannot check out these remote-tracking branches, but you can +examine them on a branch of your own, just as you would a tag: + +------------------------------------------------ +$ git checkout -b my-todo-copy origin/todo +------------------------------------------------ + +Note that the name "origin" is just the name that git uses by default +to refer to the repository that you cloned from. + +[[how-git-stores-references]] +Naming branches, tags, and other references +------------------------------------------- + +Branches, remote-tracking branches, and tags are all references to +commits. All references are named with a slash-separated path name +starting with "refs"; the names we've been using so far are actually +shorthand: + + - The branch "test" is short for "refs/heads/test". + - The tag "v2.6.18" is short for "refs/tags/v2.6.18". + - "origin/master" is short for "refs/remotes/origin/master". + +The full name is occasionally useful if, for example, there ever +exists a tag and a branch with the same name. + +As another useful shortcut, if the repository "origin" posesses only +a single branch, you can refer to that branch as just "origin". + +More generally, if you have defined a remote repository named +"example", you can refer to the branch in that repository as +"example". And for a repository with multiple branches, this will +refer to the branch designated as the "HEAD" branch. + +For the complete list of paths which git checks for references, and +the order it uses to decide which to choose when there are multiple +references with the same shorthand name, see the "SPECIFYING +REVISIONS" section of gitlink:git-rev-parse[1]. + +[[Updating-a-repository-with-git-fetch]] +Updating a repository with git fetch +------------------------------------ + +Eventually the developer cloned from will do additional work in her +repository, creating new commits and advancing the branches to point +at the new commits. + +The command "git fetch", with no arguments, will update all of the +remote-tracking branches to the latest version found in her +repository. It will not touch any of your own branches--not even the +"master" branch that was created for you on clone. + +Fetching branches from other repositories +----------------------------------------- + +You can also track branches from repositories other than the one you +cloned from, using gitlink:git-remote[1]: + +------------------------------------------------- +$ git remote add linux-nfs git://linux-nfs.org/pub/nfs-2.6.git +$ git fetch +* refs/remotes/linux-nfs/master: storing branch 'master' ... + commit: bf81b46 +------------------------------------------------- + +New remote-tracking branches will be stored under the shorthand name +that you gave "git remote add", in this case linux-nfs: + +------------------------------------------------- +$ git branch -r +linux-nfs/master +origin/master +------------------------------------------------- + +If you run "git fetch " later, the tracking branches for the +named will be updated. + +If you examine the file .git/config, you will see that git has added +a new stanza: + +------------------------------------------------- +$ cat .git/config +... +[remote "linux-nfs"] + url = git://linux-nfs.org/~bfields/git.git + fetch = +refs/heads/*:refs/remotes/linux-nfs-read/* +... +------------------------------------------------- + +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 +gitlink:git-config[1] for details.) + +Exploring git history +===================== + +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 heirarchy, together with "commits" which show +the relationships between these snapshots. + +Git provides extremely flexible and fast tools for exploring the +history of a project. + +We start with one specialized tool which is useful for finding the +commit that introduced a bug into a project. + +How to use bisect to find a regression +-------------------------------------- + +Suppose version 2.6.18 of your project worked, but the version at +"master" crashes. Sometimes the best way to find the cause of such a +regression is to perform a brute-force search through the project's +history to find the particular commit that caused the problem. The +gitlink:git-bisect[1] command can help you do this: + +------------------------------------------------- +$ git bisect start +$ git bisect good v2.6.18 +$ git bisect bad master +Bisecting: 3537 revisions left to test after this +[65934a9a028b88e83e2b0f8b36618fe503349f8e] BLOCK: Make USB storage depend on SCSI rather than selecting it [try #6] +------------------------------------------------- + +If you run "git branch" at this point, you'll see that git has +temporarily moved you to a new branch named "bisect". This branch +points to a commit (with commit id 65934...) that is reachable from +v2.6.19 but not from v2.6.18. Compile and test it, and see whether +it crashes. Assume it does crash. Then: + +------------------------------------------------- +$ git bisect bad +Bisecting: 1769 revisions left to test after this +[7eff82c8b1511017ae605f0c99ac275a7e21b867] i2c-core: Drop useless bitmaskings +------------------------------------------------- + +checks out an older version. Continue like this, telling git at each +stage whether the version it gives you is good or bad, and notice +that the number of revisions left to test is cut approximately in +half each time. + +After about 13 tests (in this case), it will output the commit id of +the guilty commit. You can then examine the commit with +gitlink:git-show[1], find out who wrote it, and mail them your bug +report with the commit id. Finally, run + +------------------------------------------------- +$ git bisect reset +------------------------------------------------- + +to return you to the branch you were on before and delete the +temporary "bisect" branch. + +Note that the version which git-bisect checks out for you at each +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 +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 + - branch name: refers to the commit at the head of the given + branch + - tag name: refers to the commit pointed to by the given tag + (we've seen branches and tags are special cases of + <>). + - HEAD: refers to the head of the current branch + +There are many more; see the "SPECIFYING REVISIONS" section of the +gitlink:git-rev-parse[1] man page for the complete list of ways to +name revisions. Some examples: + +------------------------------------------------- +$ git show fb47ddb2 # the first few characters of the object name + # are usually enough to specify it uniquely +$ git show HEAD^ # the parent of the HEAD commit +$ git show HEAD^^ # the grandparent +$ git show HEAD~4 # the great-great-grandparent +------------------------------------------------- + +Recall that merge commits may have more than one parent; by default, +^ and ~ follow the first parent listed in the commit, but you can +also choose: + +------------------------------------------------- +$ git show HEAD^1 # show the first parent of HEAD +$ git show HEAD^2 # show the second parent of HEAD +------------------------------------------------- + +In addition to HEAD, there are several other special names for +commits: + +Merges (to be discussed later), as well as operations such as +git-reset, which change the currently checked-out commit, generally +set ORIG_HEAD to the value HEAD had before the current operation. + +The git-fetch operation always stores the head of the last fetched +branch in FETCH_HEAD. For example, if you run git fetch without +specifying a local branch as the target of the operation + +------------------------------------------------- +$ git fetch git://example.com/proj.git theirbranch +------------------------------------------------- + +the fetched commits will still be available from FETCH_HEAD. + +When we discuss merges we'll also see the special name MERGE_HEAD, +which refers to the other branch that we're merging in to the current +branch. + +The gitlink:git-rev-parse[1] command is a low-level command that is +occasionally useful for translating some name for a commit to the object +name for that commit: + +------------------------------------------------- +$ git rev-parse origin +e05db0fd4f31dde7005f075a84f96b360d05984b +------------------------------------------------- + +Creating tags +------------- + +We can also create a tag to refer to a particular commit; after +running + +------------------------------------------------- +$ git-tag stable-1 1b2e1d63ff +------------------------------------------------- + +You can use stable-1 to refer to the commit 1b2e1d63ff. + +This creates a "lightweight" tag. If the tag is a tag you wish to +share with others, and possibly sign cryptographically, then you +should create a tag object instead; see the gitlink:git-tag[1] man +page for details. + +Browsing revisions +------------------ + +The gitlink:git-log[1] command can show lists of commits. On its +own, it shows all commits reachable from the parent commit; but you +can also make more specific requests: + +------------------------------------------------- +$ git log v2.5.. # commits since (not reachable from) v2.5 +$ git log test..master # commits reachable from master but not test +$ git log master..test # ...reachable from test but not master +$ git log master...test # ...reachable from either test or master, + # but not both +$ git log --since="2 weeks ago" # commits from the last 2 weeks +$ git log Makefile # commits which modify Makefile +$ git log fs/ # ... which modify any file under fs/ +$ git log -S'foo()' # commits which add or remove any file data + # matching the string 'foo()' +------------------------------------------------- + +And of course you can combine all of these; the following finds +commits since v2.5 which touch the Makefile or any file under fs: + +------------------------------------------------- +$ git log v2.5.. Makefile fs/ +------------------------------------------------- + +You can also ask git log to show patches: + +------------------------------------------------- +$ git log -p +------------------------------------------------- + +See the "--pretty" option in the gitlink:git-log[1] man page for more +display options. + +Note that git log starts with the most recent commit and works +backwards through the parents; however, since git history can contain +multiple independant lines of development, the particular order that +commits are listed in may be somewhat arbitrary. + +Generating diffs +---------------- + +You can generate diffs between any two versions using +gitlink:git-diff[1]: + +------------------------------------------------- +$ git diff master..test +------------------------------------------------- + +Sometimes what you want instead is a set of patches: + +------------------------------------------------- +$ git format-patch master..test +------------------------------------------------- + +will generate a file with a patch for each commit reachable from test +but not from master. Note that if master also has commits which are +not reachable from test, then the combined result of these patches +will not be the same as the diff produced by the git-diff example. + +Viewing old file versions +------------------------- + +You can always view an old version of a file by just checking out the +correct revision first. But sometimes it is more convenient to be +able to view an old version of a single file without checking +anything out; this command does that: + +------------------------------------------------- +$ git show v2.5:fs/locks.c +------------------------------------------------- + +Before the colon may be anything that names a commit, and after it +may be any path to a file tracked by git. + +Examples +-------- + +Check whether two branches point at the same history +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Suppose you want to check whether two branches point at the same point +in history. + +------------------------------------------------- +$ git diff origin..master +------------------------------------------------- + +will tell you whether the contents of the project are the same at the +two branches; in theory, however, it's possible that the same project +contents could have been arrived at by two different historical +routes. You could compare the object names: + +------------------------------------------------- +$ git rev-list origin +e05db0fd4f31dde7005f075a84f96b360d05984b +$ git rev-list master +e05db0fd4f31dde7005f075a84f96b360d05984b +------------------------------------------------- + +Or you could recall that the ... operator selects all commits +contained reachable from either one reference or the other but not +both: so + +------------------------------------------------- +$ git log origin...master +------------------------------------------------- + +will return no commits when the two branches are equal. + +Find first tagged version including a given fix +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Suppose you know that the commit e05db0fd fixed a certain problem. +You'd like to find the earliest tagged release that contains that +fix. + +Of course, there may be more than one answer--if the history branched +after commit e05db0fd, then there could be multiple "earliest" tagged +releases. + +You could just visually inspect the commits since e05db0fd: + +------------------------------------------------- +$ gitk e05db0fd.. +------------------------------------------------- + +Or you can use gitlink:git-name-rev[1], which will give the commit a +name based on any tag it finds pointing to one of the commit's +descendants: + +------------------------------------------------- +$ git name-rev e05db0fd +e05db0fd tags/v1.5.0-rc1^0~23 +------------------------------------------------- + +The gitlink:git-describe[1] command does the opposite, naming the +revision using a tag on which the given commit is based: + +------------------------------------------------- +$ git describe e05db0fd +v1.5.0-rc0-ge05db0f +------------------------------------------------- + +but that may sometimes help you guess which tags might come after the +given commit. + +If you just want to verify whether a given tagged version contains a +given commit, you could use gitlink:git-merge-base[1]: + +------------------------------------------------- +$ git merge-base e05db0fd v1.5.0-rc1 +e05db0fd4f31dde7005f075a84f96b360d05984b +------------------------------------------------- + +The merge-base command finds a common ancestor of the given commits, +and always returns one or the other in the case where one is a +descendant of the other; so the above output shows that e05db0fd +actually is an ancestor of v1.5.0-rc1. + +Alternatively, note that + +------------------------------------------------- +$ git log v1.5.0-rc1..e05db0fd +------------------------------------------------- + +will produce empty output if and only if v1.5.0-rc1 includes e05db0fd, +because it outputs only commits that are not reachable from v1.5.0-rc1. + +As yet another alternative, the gitlink:git-show-branch[1] command lists +the commits reachable from its arguments with a display on the left-hand +side that indicates which arguments that commit is reachable from. So, +you can run something like + +------------------------------------------------- +$ git show-branch e05db0fd v1.5.0-rc0 v1.5.0-rc1 v1.5.0-rc2 +! [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if +available + ! [v1.5.0-rc0] GIT v1.5.0 preview + ! [v1.5.0-rc1] GIT v1.5.0-rc1 + ! [v1.5.0-rc2] GIT v1.5.0-rc2 +... +------------------------------------------------- + +then search for a line that looks like + +------------------------------------------------- ++ ++ [e05db0fd] Fix warnings in sha1_file.c - use C99 printf format if +available +------------------------------------------------- + +Which shows that e05db0fd is reachable from itself, from v1.5.0-rc1, and +from v1.5.0-rc2, but not from v1.5.0-rc0. + + +Developing with git +=================== + +Telling git your name +--------------------- + +Before creating any commits, you should introduce yourself to git. The +easiest way to do so is: + +------------------------------------------------ +$ cat >~/.gitconfig <<\EOF +[user] + name = Your Name Comes Here + email = you@yourdomain.example.com +EOF +------------------------------------------------ + +(See the "CONFIGURATION FILE" section of gitlink:git-config[1] for +details on the configuration file.) + + +Creating a new repository +------------------------- + +Creating a new repository from scratch is very easy: + +------------------------------------------------- +$ mkdir project +$ cd project +$ git init +------------------------------------------------- + +If you have some initial content (say, a tarball): + +------------------------------------------------- +$ tar -xzvf project.tar.gz +$ cd project +$ git init +$ git add . # include everything below ./ in the first commit: +$ git commit +------------------------------------------------- + +[[how-to-make-a-commit]] +how to make a commit +-------------------- + +Creating a new commit takes three steps: + + 1. Making some changes to the working directory using your + favorite editor. + 2. Telling git about your changes. + 3. Creating the commit using the content you told git about + in step 2. + +In practice, you can interleave and repeat steps 1 and 2 as many +times as you want: in order to keep track of what you want committed +at step 3, git maintains a snapshot of the tree's contents in a +special staging area called "the index." + +At the beginning, the content of the index will be identical to +that of the HEAD. The command "git diff --cached", which shows +the difference between the HEAD and the index, should therefore +produce no output at that point. + +Modifying the index is easy: + +To update the index with the new contents of a modified file, use + +------------------------------------------------- +$ git add path/to/file +------------------------------------------------- + +To add the contents of a new file to the index, use + +------------------------------------------------- +$ git add path/to/file +------------------------------------------------- + +To remove a file from the index and from the working tree, + +------------------------------------------------- +$ git rm path/to/file +------------------------------------------------- + +After each step you can verify that + +------------------------------------------------- +$ git diff --cached +------------------------------------------------- + +always shows the difference between the HEAD and the index file--this +is what you'd commit if you created the commit now--and that + +------------------------------------------------- +$ git diff +------------------------------------------------- + +shows the difference between the working tree and the index file. + +Note that "git add" always adds just the current contents of a file +to the index; further changes to the same file will be ignored unless +you run git-add on the file again. + +When you're ready, just run + +------------------------------------------------- +$ git commit +------------------------------------------------- + +and git will prompt you for a commit message and then create the new +commmit. Check to make sure it looks like what you expected with + +------------------------------------------------- +$ git show +------------------------------------------------- + +As a special shortcut, + +------------------------------------------------- +$ git commit -a +------------------------------------------------- + +will update the index with any files that you've modified or removed +and create a commit, all in one step. + +A number of commands are useful for keeping track of what you're +about to commit: + +------------------------------------------------- +$ git diff --cached # difference between HEAD and the index; what + # would be commited if you ran "commit" now. +$ git diff # difference between the index file and your + # working directory; changes that would not + # be included if you ran "commit" now. +$ git status # a brief per-file summary of the above. +------------------------------------------------- + +creating good commit messages +----------------------------- + +Though not required, it's a good idea to begin the commit message +with a single short (less than 50 character) line summarizing the +change, followed by a blank line and then a more thorough +description. Tools that turn commits into email, for example, use +the first line on the Subject line and the rest of the commit in the +body. + +how to merge +------------ + +You can rejoin two diverging branches of development using +gitlink: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 +branch--then you are warned; the output may look something like this: + +------------------------------------------------- +$ git pull . next +Trying really trivial in-index merge... +fatal: Merge requires file-level merging +Nope. +Merging HEAD with 77976da35a11db4580b80ae27e8d65caf5208086 +Merging: +15e2162 world +77976da goodbye +found 1 common ancestor(s): +d122ed4 initial +Auto-merging file.txt +CONFLICT (content): Merge conflict in file.txt +Automatic merge failed; fix conflicts and then commit the result. +------------------------------------------------- + +Conflict markers are left in the problematic files, and after +you resolve the conflicts manually, you can update the index +with the contents and run git commit, as you normally would when +creating a new file. + +If you examine the resulting commit using gitk, you will see that it +has two parents, one pointing to the top of the current branch, and +one to the top of the other branch. + +In more detail: + +[[resolving-a-merge]] +Resolving a merge +----------------- + +When a merge isn't resolved automatically, git leaves the index and +the working tree in a special state that gives you all the +information you need to help resolve the merge. + +Files with conflicts are marked specially in the index, so until you +resolve the problem and update the index, git commit will fail: + +------------------------------------------------- +$ git commit +file.txt: needs merge +------------------------------------------------- + +Also, git status will list those files as "unmerged". + +All of the changes that git was able to merge automatically are +already added to the index file, so gitlink:git-diff[1] shows only +the conflicts. Also, it uses a somewhat unusual syntax: + +------------------------------------------------- +$ git diff +diff --cc file.txt +index 802992c,2b60207..0000000 +--- a/file.txt ++++ b/file.txt +@@@ -1,1 -1,1 +1,5 @@@ +++<<<<<<< HEAD:file.txt + +Hello world +++======= ++ Goodbye +++>>>>>>> 77976da35a11db4580b80ae27e8d65caf5208086:file.txt +------------------------------------------------- + +Recall that the commit which will be commited after we resolve this +conflict will have two parents instead of the usual one: one parent +will be HEAD, the tip of the current branch; the other will be the +tip of the other branch, which is stored temporarily in MERGE_HEAD. + +The diff above shows the differences between the working-tree version +of file.txt and two previous version: one version from HEAD, and one +from MERGE_HEAD. So instead of preceding each line by a single "+" +or "-", it now uses two columns: the first column is used for +differences between the first parent and the working directory copy, +and the second for differences between the second parent and the +working directory copy. Thus after resolving the conflict in the +obvious way, the diff will look like: + +------------------------------------------------- +$ git diff +diff --cc file.txt +index 802992c,2b60207..0000000 +--- a/file.txt ++++ b/file.txt +@@@ -1,1 -1,1 +1,1 @@@ +- Hello world + -Goodbye +++Goodbye world +------------------------------------------------- + +This shows that our resolved version deleted "Hello world" from the +first parent, deleted "Goodbye" from the second parent, and added +"Goodbye world", which was previously absent from both. + +The gitlink:git-log[1] command also provides special help for merges: + +------------------------------------------------- +$ git log --merge +------------------------------------------------- + +This will list all commits which exist only on HEAD or on MERGE_HEAD, +and which touch an unmerged file. + +We can now add the resolved version to the index and commit: + +------------------------------------------------- +$ git add file.txt +$ git commit +------------------------------------------------- + +Note that the commit message will already be filled in for you with +some information about the merge. Normally you can just use this +default message unchanged, but you may add additional commentary of +your own if desired. + +[[undoing-a-merge]] +undoing a merge +--------------- + +If you get stuck and decide to just give up and throw the whole mess +away, you can always return to the pre-merge state with + +------------------------------------------------- +$ git reset --hard HEAD +------------------------------------------------- + +Or, if you've already commited the merge that you want to throw away, + +------------------------------------------------- +$ git reset --hard HEAD^ +------------------------------------------------- + +However, this last command can be dangerous in some cases--never +throw away a commit you have already committed if that commit may +itself have been merged into another branch, as doing so may confuse +further merges. + +Fast-forward merges +------------------- + +There is one special case not mentioned above, which is treated +differently. Normally, a merge results in a merge commit, with two +parents, one pointing at each of the two lines of development that +were merged. + +However, if one of the two lines of development is completely +contained within the other--so every commit present in the one is +already contained in the other--then git just performs a +<>; the head of the current branch is +moved forward to point at the head of the merged-in branch, without +any new commits being created. + +Fixing mistakes +--------------- + +If you've messed up the working tree, but haven't yet committed your +mistake, you can return the entire working tree to the last committed +state with + +------------------------------------------------- +$ git reset --hard HEAD +------------------------------------------------- + +If you make a commit that you later wish you hadn't, there are two +fundamentally different ways to fix the problem: + + 1. You can create a new commit that undoes whatever was done + by the previous commit. This is the correct thing if your + mistake has already been made public. + + 2. You can go back and modify the old commit. You should + never do this if you have already made the history public; + git does not normally expect the "history" of a project to + change, and cannot correctly perform repeated merges from + a branch that has had its history changed. + +Fixing a mistake with a new commit +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Creating a new commit that reverts an earlier change is very easy; +just pass the gitlink:git-revert[1] command a reference to the bad +commit; for example, to revert the most recent commit: + +------------------------------------------------- +$ git revert HEAD +------------------------------------------------- + +This will create a new commit which undoes the change in HEAD. You +will be given a chance to edit the commit message for the new commit. + +You can also revert an earlier change, for example, the next-to-last: + +------------------------------------------------- +$ git revert HEAD^ +------------------------------------------------- + +In this case git will attempt to undo the old change while leaving +intact any changes made since then. If more recent changes overlap +with the changes to be reverted, then you will be asked to fix +conflicts manually, just as in the case of <>. + +Fixing a mistake by editing history +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If the problematic commit is the most recent commit, and you have not +yet made that commit public, then you may just +<>. + +Alternatively, you +can edit the working directory and update the index to fix your +mistake, just as if you were going to <>, then run + +------------------------------------------------- +$ git commit --amend +------------------------------------------------- + +which will replace the old commit by a new commit incorporating your +changes, giving you a chance to edit the old commit message first. + +Again, you should never do this to a commit that may already have +been merged into another branch; use gitlink:git-revert[1] instead in +that case. + +It is also possible to edit commits further back in the history, but +this is an advanced topic to be left for +<>. + +Checking out an old version of a file +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the process of undoing a previous bad change, you may find it +useful to check out an older version of a particular file using +gitlink:git-checkout[1]. We've used git checkout before to switch +branches, but it has quite different behavior if it is given a path +name: the command + +------------------------------------------------- +$ git checkout HEAD^ path/to/file +------------------------------------------------- + +replaces path/to/file by the contents it had in the commit HEAD^, and +also updates the index to match. It does not change branches. + +If you just want to look at an old version of the file, without +modifying the working directory, you can do that with +gitlink:git-show[1]: + +------------------------------------------------- +$ git show HEAD^ path/to/file +------------------------------------------------- + +which will display the given version of the file. + +Ensuring good performance +------------------------- + +On large repositories, git depends on compression to keep the history +information from taking up to much space on disk or in memory. + +This compression is not performed automatically. Therefore you +should occasionally run gitlink:git-gc[1]: + +------------------------------------------------- +$ git gc +------------------------------------------------- + +to recompress the archive. This can be very time-consuming, so +you may prefer to run git-gc when you are not doing other work. + +Ensuring reliability +-------------------- + +Checking the repository for corruption +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The gitlink:git-fsck[1] command runs a number of self-consistency checks +on the repository, and reports on any problems. This may take some +time. The most common warning by far is about "dangling" objects: + +------------------------------------------------- +$ git fsck +dangling commit 7281251ddd2a61e38657c827739c57015671a6b3 +dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63 +dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5 +dangling blob 218761f9d90712d37a9c5e36f406f92202db07eb +dangling commit bf093535a34a4d35731aa2bd90fe6b176302f14f +dangling commit 8e4bec7f2ddaa268bef999853c25755452100f8e +dangling tree d50bb86186bf27b681d25af89d3b5b68382e4085 +dangling tree b24c2473f1fd3d91352a624795be026d64c8841f +... +------------------------------------------------- + +Dangling objects are objects that are harmless, but also unnecessary; +you can remove them at any time with gitlink:git-prune[1] or the --prune +option to gitlink:git-gc[1]: + +------------------------------------------------- +$ git gc --prune +------------------------------------------------- + +This may be time-consuming. Unlike most other git operations (including +git-gc when run without any options), it is not safe to prune while +other git operations are in progress in the same repository. + +For more about dangling objects, see <>. + + +Recovering lost changes +~~~~~~~~~~~~~~~~~~~~~~~ + +Reflogs +^^^^^^^ + +Say you modify a branch with gitlink:git-reset[1] --hard, and then +realize that the branch was the only reference you had to that point in +history. + +Fortunately, git also keeps a log, called a "reflog", of all the +previous values of each branch. So in this case you can still find the +old history using, for example, + +------------------------------------------------- +$ git log master@{1} +------------------------------------------------- + +This lists the commits reachable from the previous version of the head. +This syntax can be used to with any git command that accepts a commit, +not just with git log. Some other examples: + +------------------------------------------------- +$ git show master@{2} # See where the branch pointed 2, +$ git show master@{3} # 3, ... changes ago. +$ gitk master@{yesterday} # See where it pointed yesterday, +$ gitk master@{"1 week ago"} # ... or last week +------------------------------------------------- + +The reflogs are kept by default for 30 days, after which they may be +pruned. See gitlink:git-reflog[1] and gitlink:git-gc[1] to learn +how to control this pruning, and see the "SPECIFYING REVISIONS" +section of gitlink:git-rev-parse[1] for details. + +Note that the reflog history is very different from normal git history. +While normal history is shared by every repository that works on the +same project, the reflog history is not shared: it tells you only about +how the branches in your local repository have changed over time. + +Examining dangling objects +^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In some situations the reflog may not be able to save you. For +example, suppose you delete a branch, then realize you need the history +it pointed you. The reflog is also deleted; however, if you have not +yet pruned the repository, then you may still be able to find +the lost commits; run git-fsck and watch for output that mentions +"dangling commits": + +------------------------------------------------- +$ git fsck +dangling commit 7281251ddd2a61e38657c827739c57015671a6b3 +dangling commit 2706a059f258c6b245f298dc4ff2ccd30ec21a63 +dangling commit 13472b7c4b80851a1bc551779171dcb03655e9b5 +... +------------------------------------------------- + +and watch for output that mentions "dangling commits". You can examine +one of those dangling commits with, for example, + +------------------------------------------------ +$ gitk 7281251ddd --not --all +------------------------------------------------ + +which does what it sounds like: it says that you want to see the commit +history that is described by the dangling commit(s), but not the +history that is described by all your existing branches and tags. Thus +you get exactly the history reachable from that commit that is lost. +(And notice that it might not be just one commit: we only report the +"tip of the line" as being dangling, but there might be a whole deep +and complex commit history that was gotten dropped.) + +If you decide you want the history back, you can always create a new +reference pointing to it, for example, a new branch: + +------------------------------------------------ +$ git branch recovered-branch 7281251ddd +------------------------------------------------ + + +Sharing development with others +=============================== + +[[getting-updates-with-git-pull]] +Getting updates with git pull +----------------------------- + +After you clone a repository and make a few changes of your own, you +may wish to check the original repository for updates and merge them +into your own work. + +We have already seen <> with gitlink:git-fetch[1], +and how to merge two branches. So you can merge in changes from the +original repository's master branch with: + +------------------------------------------------- +$ git fetch +$ git merge origin/master +------------------------------------------------- + +However, the gitlink:git-pull[1] command provides a way to do this in +one step: + +------------------------------------------------- +$ git pull origin master +------------------------------------------------- + +In fact, "origin" is normally the default repository to pull from, +and the default branch is normally the HEAD of the remote repository, +so often you can accomplish the above with just + +------------------------------------------------- +$ git pull +------------------------------------------------- + +See the descriptions of the branch..remote and +branch..merge options in gitlink:git-config[1] to learn +how to control these defaults depending on the current branch. + +In addition to saving you keystrokes, "git pull" also helps you by +producing a default commit message documenting the branch and +repository that you pulled from. + +(But note that no such commit will be created in the case of a +<>; instead, your branch will just be +updated to point to the latest commit from the upstream branch). + +The git-pull command can also be given "." as the "remote" repository, +in which case it just merges in a branch from the current repository; so +the commands + +------------------------------------------------- +$ git pull . branch +$ git merge branch +------------------------------------------------- + +are roughly equivalent. The former is actually very commonly used. + +Submitting patches to a project +------------------------------- + +If you just have a few changes, the simplest way to submit them may +just be to send them as patches in email: + +First, use gitlink:git-format-patch[1]; for example: + +------------------------------------------------- +$ git format-patch origin +------------------------------------------------- + +will produce a numbered series of files in the current directory, one +for each patch in the current branch but not in origin/HEAD. + +You can then import these into your mail client and send them by +hand. However, if you have a lot to send at once, you may prefer to +use the gitlink:git-send-email[1] script to automate the process. +Consult the mailing list for your project first to determine how they +prefer such patches be handled. + +Importing patches to a project +------------------------------ + +Git also provides a tool called gitlink:git-am[1] (am stands for +"apply mailbox"), for importing such an emailed series of patches. +Just save all of the patch-containing messages, in order, into a +single mailbox file, say "patches.mbox", then run + +------------------------------------------------- +$ git am -3 patches.mbox +------------------------------------------------- + +Git will apply each patch in order; if any conflicts are found, it +will stop, and you can fix the conflicts as described in +"<>". (The "-3" option tells +git to perform a merge; if you would prefer it just to abort and +leave your tree and index untouched, you may omit that option.) + +Once the index is updated with the results of the conflict +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. + +[[setting-up-a-public-repository]] +Setting up a public repository +------------------------------ + +Another way to submit changes to a project is to simply tell the +maintainer of that project to pull from your repository, exactly as +you did in the section "<>". + +If you and maintainer both have accounts on the same machine, then +then you can just pull changes from each other's repositories +directly; note that all of the command (gitlink:git-clone[1], +git-fetch[1], git-pull[1], etc.) which accept a URL as an argument +will also accept a local file patch; so, for example, you can +use + +------------------------------------------------- +$ git clone /path/to/repository +$ git pull /path/to/other/repository +------------------------------------------------- + +If this sort of setup is inconvenient or impossible, another (more +common) option is to set up a public repository on a public server. +This also allows you to cleanly separate private work in progress +from publicly visible work. + +You will continue to do your day-to-day work in your personal +repository, but periodically "push" changes from your personal +repository into your public repository, allowing other developers to +pull from that repository. So the flow of changes, in a situation +where there is one other developer with a public repository, looks +like this: + + you push + your personal repo ------------------> your public repo + ^ | + | | + | you pull | they pull + | | + | | + | they push V + their public repo <------------------- their repo + +Now, assume your personal repository is in the directory ~/proj. We +first create a new clone of the repository: + +------------------------------------------------- +$ git clone --bare proj-clone.git +------------------------------------------------- + +The resulting directory proj-clone.git will contains a "bare" git +repository--it is just the contents of the ".git" directory, without +a checked-out copy of a working directory. + +Next, copy proj-clone.git to the server where you plan to host the +public repository. You can use scp, rsync, or whatever is most +convenient. + +If somebody else maintains the public server, they may already have +set up a git service for you, and you may skip to the section +"<>", below. + +Otherwise, the following sections explain how to export your newly +created public repository: + +[[exporting-via-http]] +Exporting a git repository via http +----------------------------------- + +The git protocol gives better performance and reliability, but on a +host with a web server set up, http exports may be simpler to set up. + +All you need to do is place the newly created bare git repository in +a directory that is exported by the web server, and make some +adjustments to give web clients some extra information they need: + +------------------------------------------------- +$ mv proj.git /home/you/public_html/proj.git +$ cd proj.git +$ git update-server-info +$ chmod a+x hooks/post-update +------------------------------------------------- + +(For an explanation of the last two lines, see +gitlink:git-update-server-info[1], and the documentation +link:hooks.txt[Hooks used by git].) + +Advertise the url of proj.git. Anybody else should then be able to +clone or pull from that url, for example with a commandline like: + +------------------------------------------------- +$ git clone http://yourserver.com/~you/proj.git +------------------------------------------------- + +(See also +link:howto/setup-git-server-over-http.txt[setup-git-server-over-http] +for a slightly more sophisticated setup using WebDAV which also +allows pushing over http.) + +[[exporting-via-git]] +Exporting a git repository via the git protocol +----------------------------------------------- + +This is the preferred method. + +For now, we refer you to the gitlink:git-daemon[1] man page for +instructions. (See especially the examples section.) + +[[pushing-changes-to-a-public-repository]] +Pushing changes to a public repository +-------------------------------------- + +Note that the two techniques outline above (exporting via +<> or <>) allow other +maintainers to fetch your latest changes, but they do not allow write +access, which you will need to update the public repository with the +latest changes created in your private repository. + +The simplest way to do this is using gitlink:git-push[1] and ssh; to +update the remote branch named "master" with the latest state of your +branch named "master", run + +------------------------------------------------- +$ git push ssh://yourserver.com/~you/proj.git master:master +------------------------------------------------- + +or just + +------------------------------------------------- +$ git push ssh://yourserver.com/~you/proj.git master +------------------------------------------------- + +As with git-fetch, git-push will complain if this does not result in +a <>. Normally this is a sign of +something wrong. However, if you are sure you know what you're +doing, you may force git-push to perform the update anyway by +proceeding the branch name by a plus sign: + +------------------------------------------------- +$ git push ssh://yourserver.com/~you/proj.git +master +------------------------------------------------- + +As with git-fetch, you may also set up configuration options to +save typing; so, for example, after + +------------------------------------------------- +$ cat >.git/config <.url, branch..remote, +and remote..push options in gitlink:git-config[1] for +details. + +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 +all push to and pull from a single shared repository. See +link:cvs-migration.txt[git for CVS users] for instructions on how to +set this up. + +Allow web browsing of a repository +---------------------------------- + +The gitweb cgi script provides users an easy way to browse your +project's files and history without having to install git; see the file +gitweb/README in the git source tree for instructions on setting it up. + +Examples +-------- + +TODO: topic branches, typical roles as in everyday.txt, ? + + +[[cleaning-up-history]] +Rewriting history and maintaining patch series +============================================== + +Normally commits are only added to a project, never taken away or +replaced. Git is designed with this assumption, and violating it will +cause git's merge machinery (for example) to do the wrong thing. + +However, there is a situation in which it can be useful to violate this +assumption. + +Creating the perfect patch series +--------------------------------- + +Suppose you are a contributor to a large project, and you want to add a +complicated feature, and to present it to the other developers in a way +that makes it easy for them to read your changes, verify that they are +correct, and understand why you made each change. + +If you present all of your changes as a single patch (or commit), they +may find it is too much to digest all at once. + +If you present them with the entire history of your work, complete with +mistakes, corrections, and dead ends, they may be overwhelmed. + +So the ideal is usually to produce a series of patches such that: + + 1. Each patch can be applied in order. + + 2. Each patch includes a single logical change, together with a + message explaining the change. + + 3. No patch introduces a regression: after applying any initial + part of the series, the resulting project still compiles and + works, and has no bugs that it didn't have before. + + 4. The complete series produces the same end result as your own + (probably much messier!) development process did. + +We will introduce some tools that can help you do this, explain how to +use them, and then explain some of the problems that can arise because +you are rewriting history. + +Keeping a patch series up to date using git-rebase +-------------------------------------------------- + +Suppose you have a series of commits in a branch "mywork", which +originally branched off from "origin". + +Suppose you create a branch "mywork" on a remote-tracking branch +"origin", and created some commits on top of it: + +------------------------------------------------- +$ git checkout -b mywork origin +$ vi file.txt +$ git commit +$ vi otherfile.txt +$ git commit +... +------------------------------------------------- + +You have performed no merges into mywork, so it is just a simple linear +sequence of patches on top of "origin": + + + o--o--o <-- origin + \ + o--o--o <-- mywork + +Some more interesting work has been done in the upstream project, and +"origin" has advanced: + + o--o--O--o--o--o <-- origin + \ + a--b--c <-- mywork + +At this point, you could use "pull" to merge your changes back in; +the result would create a new merge commit, like this: + + + o--o--O--o--o--o <-- origin + \ \ + a--b--c--m <-- mywork + +However, if you prefer to keep the history in mywork a simple series of +commits without any merges, you may instead choose to use +gitlink:git-rebase[1]: + +------------------------------------------------- +$ git checkout mywork +$ git rebase origin +------------------------------------------------- + +This will remove each of your commits from mywork, temporarily saving +them as patches (in a directory named ".dotest"), update mywork to +point at the latest version of origin, then apply each of the saved +patches to the new mywork. The result will look like: + + + o--o--O--o--o--o <-- origin + \ + a'--b'--c' <-- mywork + +In the process, it may discover conflicts. In that case it will stop +and allow you to fix the conflicts; after fixing conflicts, use "git +add" to update the index with those contents, and then, instead of +running git-commit, just run + +------------------------------------------------- +$ git rebase --continue +------------------------------------------------- + +and git will continue applying the rest of the patches. + +At any point you may use the --abort option to abort this process and +return mywork to the state it had before you started the rebase: + +------------------------------------------------- +$ git rebase --abort +------------------------------------------------- + +Reordering or selecting from a patch series +------------------------------------------- + +Given one existing commit, the gitlink:git-cherry-pick[1] command +allows you to apply the change introduced by that commit and create a +new commit that records it. So, for example, if "mywork" points to a +series of patches on top of "origin", you might do something like: + +------------------------------------------------- +$ git checkout -b mywork-new origin +$ 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. + +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 gitlink:git-am[1]. + +Other tools +----------- + +There are numerous other tools, such as stgit, which exist for the +purpose of maintaining a patch series. These are out of the scope of +this manual. + +Problems with rewriting history +------------------------------- + +The primary problem with rewriting the history of a branch has to do +with merging. Suppose somebody fetches your branch and merges it into +their branch, with a result something like this: + + o--o--O--o--o--o <-- origin + \ \ + t--t--t--m <-- their branch: + +Then suppose you modify the last three commits: + + o--o--o <-- new head of origin + / + o--o--O--o--o--o <-- old head of origin + +If we examined all this history together in one repository, it will +look like: + + o--o--o <-- new head of origin + / + o--o--O--o--o--o <-- old head of origin + \ \ + t--t--t--m <-- their branch: + +Git has no way of knowing that the new head is an updated version of +the old head; it treats this situation exactly the same as it would if +two developers had independently done the work on the old and new heads +in parallel. At this point, if someone attempts to merge the new head +in to their branch, git will attempt to merge together the two (old and +new) lines of development, instead of trying to replace the old by the +new. The results are likely to be unexpected. + +You may still choose to publish branches whose history is rewritten, +and it may be useful for others to be able to fetch those branches in +order to examine or test them, but they should not attempt to pull such +branches into their own work. + +For true distributed development that supports proper merging, +published branches should never be rewritten. + +Advanced branch management +========================== + +Fetching individual branches +---------------------------- + +Instead of using gitlink:git-remote[1], you can also choose just +to update one branch at a time, and to store it locally under an +arbitrary name: + +------------------------------------------------- +$ git fetch origin todo:my-todo-work +------------------------------------------------- + +The first argument, "origin", just tells git to fetch from the +repository you originally cloned from. The second argument tells git +to fetch the branch named "todo" from the remote repository, and to +store it locally under the name refs/heads/my-todo-work. + +You can also fetch branches from other repositories; so + +------------------------------------------------- +$ git fetch git://example.com/proj.git master:example-master +------------------------------------------------- + +will create a new branch named "example-master" and store in it the +branch named "master" from the repository at the given URL. If you +already have a branch named example-master, it will attempt to +"fast-forward" to the commit given by example.com's master branch. So +next we explain what a fast-forward is: + +[[fast-forwards]] +Understanding git history: fast-forwards +---------------------------------------- + +In the previous example, when updating an existing branch, "git +fetch" checks to make sure that the most recent commit on the remote +branch is a descendant of the most recent commit on your copy of the +branch before updating your copy of the branch to point at the new +commit. Git calls this process a "fast forward". + +A fast forward looks something like this: + + o--o--o--o <-- old head of the branch + \ + o--o--o <-- new head of the branch + + +In some cases it is possible that the new head will *not* actually be +a descendant of the old head. For example, the developer may have +realized she made a serious mistake, and decided to backtrack, +resulting in a situation like: + + o--o--o--o--a--b <-- old head of the branch + \ + o--o--o <-- new head of the branch + + + +In this case, "git fetch" will fail, and print out a warning. + +In that case, you can still force git to update to the new head, as +described in the following section. However, note that in the +situation above this may mean losing the commits labeled "a" and "b", +unless you've already created a reference of your own pointing to +them. + +Forcing git fetch to do non-fast-forward updates +------------------------------------------------ + +If git fetch fails because the new head of a branch is not a +descendant of the old head, you may force the update with: + +------------------------------------------------- +$ git fetch git://example.com/proj.git +master:refs/remotes/example/master +------------------------------------------------- + +Note the addition of the "+" sign. Be aware that commits which the +old version of example/master pointed at may be lost, as we saw in +the previous section. + +Configuring remote branches +--------------------------- + +We saw above that "origin" is just a shortcut to refer to the +repository which you originally cloned from. This information is +stored in git configuration variables, which you can see using +gitlink:git-config[1]: + +------------------------------------------------- +$ git config -l +core.repositoryformatversion=0 +core.filemode=true +core.logallrefupdates=true +remote.origin.url=git://git.kernel.org/pub/scm/git/git.git +remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* +branch.master.remote=origin +branch.master.merge=refs/heads/master +------------------------------------------------- + +If there are other repositories that you also use frequently, you can +create similar configuration options to save typing; for example, +after + +------------------------------------------------- +$ git config remote.example.url git://example.com/proj.git +------------------------------------------------- + +then the following two commands will do the same thing: + +------------------------------------------------- +$ git fetch git://example.com/proj.git master:refs/remotes/example/master +$ git fetch example master:refs/remotes/example/master +------------------------------------------------- + +Even better, if you add one more option: + +------------------------------------------------- +$ git config remote.example.fetch master:refs/remotes/example/master +------------------------------------------------- + +then the following commands will all do the same thing: + +------------------------------------------------- +$ git fetch git://example.com/proj.git master:ref/remotes/example/master +$ git fetch example master:ref/remotes/example/master +$ git fetch example example/master +$ git fetch example +------------------------------------------------- + +You can also add a "+" to force the update each time: + +------------------------------------------------- +$ git config remote.example.fetch +master:ref/remotes/example/master +------------------------------------------------- + +Don't do this unless you're sure you won't mind "git fetch" possibly +throwing away commits on mybranch. + +Also note that all of the above configuration can be performed by +directly editing the file .git/config instead of using +gitlink:git-config[1]. + +See gitlink:git-config[1] for more details on the configuration +options mentioned above. + + +Git internals +============= + +There are two object abstractions: the "object database", and the +"current directory cache" aka "index". + +The Object Database +------------------- + +The object database is literally just a content-addressable collection +of objects. All objects are named by their content, which is +approximated by the SHA1 hash of the object itself. Objects may refer +to other objects (by referencing their SHA1 hash), and so you can +build up a hierarchy of objects. + +All objects have a statically determined "type" aka "tag", which is +determined at object creation time, and which identifies the format of +the object (i.e. how it is used, and how it can refer to other +objects). There are currently four different object types: "blob", +"tree", "commit" and "tag". + +A "blob" object cannot refer to any other object, and is, like the type +implies, a pure storage object containing some user data. It is used to +actually store the file data, i.e. a blob object is associated with some +particular version of some file. + +A "tree" object is an object that 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 "commit" object ties such directory hierarchies together into +a DAG of revisions - each "commit" is associated with exactly one tree +(the directory hierarchy at the time of the commit). In addition, a +"commit" refers to one or more "parent" commit objects that describe the +history of how we arrived at that directory hierarchy. + +As a special case, a commit object with no parents is called the "root" +object, and is the point of an initial project commit. Each project +must have at least one root, and while you can tie several different +root objects together into one project by creating a commit object which +has two or more separate roots as its ultimate parents, that's probably +just going to confuse people. So aim for the notion of "one root object +per project", even if git itself does not enforce that. + +A "tag" object symbolically identifies and can be used to sign other +objects. It contains the identifier and type of another object, a +symbolic name (of course!) and, optionally, a signature. + +Regardless of object type, all objects share the following +characteristics: they are all deflated with zlib, and have a header +that not only specifies their type, but also provides size information +about the data in the object. It's worth noting that the SHA1 hash +that is used to name the object is the hash of the original data +plus this header, so `sha1sum` 'file' does not match the object name +for 'file'. +(Historical note: in the dawn of the age of git the hash +was the sha1 of the 'compressed' object.) + +As a result, the general consistency of an object can always be tested +independently of the contents or the type of the object: all objects can +be validated by verifying that (a) their hashes match the content of the +file and (b) the object successfully inflates to a stream of bytes that +forms a sequence of + + + + . + +The structured objects can further have their structure and +connectivity to other objects verified. This is generally done with +the `git-fsck` program, which generates a full dependency graph +of all objects, and verifies their internal consistency (in addition +to just verifying their superficial consistency through the hash). + +The object types in some more detail: + +Blob Object +----------- + +A "blob" object is nothing but a binary blob of data, and doesn't +refer to anything else. There is no signature or any other +verification of the data, so while the object is consistent (it 'is' +indexed by its sha1 hash, so the data itself is certainly correct), it +has absolutely no other attributes. No name associations, no +permissions. It is purely a blob of data (i.e. normally "file +contents"). + +In particular, since the blob is entirely defined by its data, if two +files in a directory tree (or in multiple different versions of the +repository) have the same contents, they will share the same blob +object. The object is totally independent of its location in the +directory tree, and renaming a file does not change the object that +file is associated with in any way. + +A blob is typically created when gitlink:git-update-index[1] +is run, and its data can be accessed by gitlink:git-cat-file[1]. + +Tree Object +----------- + +The next hierarchical object type is the "tree" object. A tree object +is a list of mode/name/blob data, sorted by name. Alternatively, the +mode data may specify a directory mode, in which case instead of +naming a blob, that name is associated with another TREE object. + +Like the "blob" object, a tree object is uniquely determined by the +set contents, and so two separate but identical trees will always +share the exact same object. This is true at all levels, i.e. it's +true for a "leaf" tree (which does not refer to any other trees, only +blobs) as well as for a whole subdirectory. + +For that reason a "tree" object is just a pure data abstraction: it +has no history, no signatures, no verification of validity, except +that since the contents are again protected by the hash itself, we can +trust that the tree is immutable and its contents never change. + +So you can trust the contents of a tree to be valid, the same way you +can trust the contents of a blob, but you don't know where those +contents 'came' from. + +Side note on trees: since a "tree" object is a sorted list of +"filename+content", you can create a diff between two trees without +actually having to unpack two trees. Just ignore all common parts, +and your diff will look right. In other words, you can effectively +(and efficiently) tell the difference between any two random trees by +O(n) where "n" is the size of the difference, rather than the size of +the tree. + +Side note 2 on trees: since the name of a "blob" depends entirely and +exclusively on its contents (i.e. there are no names or permissions +involved), you can see trivial renames or permission changes by +noticing that the blob stayed the same. However, renames with data +changes need a smarter "diff" implementation. + +A tree is created with gitlink:git-write-tree[1] and +its data can be accessed by gitlink:git-ls-tree[1]. +Two trees can be compared with gitlink:git-diff-tree[1]. + +Commit Object +------------- + +The "commit" object is an object that introduces the notion of +history into the picture. In contrast to the other objects, it +doesn't just describe the physical state of a tree, it describes how +we got there, and why. + +A "commit" is defined by the tree-object that it results in, the +parent commits (zero, one or more) that led up to that point, and a +comment on what happened. Again, a commit is not trusted per se: +the contents are well-defined and "safe" due to the cryptographically +strong signatures at all levels, but there is no reason to believe +that the tree is "good" or that the merge information makes sense. +The parents do not have to actually have any relationship with the +result, for example. + +Note on commits: unlike real SCM's, commits do not contain +rename information or file mode change information. All of that is +implicit in the trees involved (the result tree, and the result trees +of the parents), and describing that makes no sense in this idiotic +file manager. + +A commit is created with gitlink:git-commit-tree[1] and +its data can be accessed by gitlink:git-cat-file[1]. + +Trust +----- + +An aside on the notion of "trust". Trust is really outside the scope +of "git", but it's worth noting a few things. First off, since +everything is hashed with SHA1, you 'can' trust that an object is +intact and has not been messed with by external sources. So the name +of an object uniquely identifies a known state - just not a state that +you may want to trust. + +Furthermore, since the SHA1 signature of a commit refers to the +SHA1 signatures of the tree it is associated with and the signatures +of the parent, a single named commit specifies uniquely a whole set +of history, with full contents. You can't later fake any step of the +way once you have the name of a commit. + +So to introduce some real trust in the system, the only thing you need +to do is to digitally sign just 'one' special note, which includes the +name of a top-level commit. Your digital signature shows others +that you trust that commit, and the immutability of the history of +commits tells others that they can trust the whole history. + +In other words, you can easily validate a whole archive by just +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 +---------- + +Git provides the "tag" object to simplify creating, managing and +exchanging symbolic and signed tokens. The "tag" object at its +simplest simply symbolically identifies another object by containing +the sha1, type and symbolic name. + +However it can optionally contain additional signature information +(which git doesn't care about as long as there's less than 8k of +it). This can then be verified externally to git. + +Note that despite the tag features, "git" itself only handles content +integrity; the trust framework (and signature provision and +verification) has to come from outside. + +A tag is created with gitlink:git-mktag[1], +its data can be accessed by gitlink:git-cat-file[1], +and the signature can be verified by +gitlink:git-verify-tag[1]. + + +The "index" aka "Current Directory Cache" +----------------------------------------- + +The index is a simple binary file, which contains an efficient +representation of a virtual directory content at some random time. It +does so by a simple array that associates a set of names, dates, +permissions and content (aka "blob") objects together. The cache is +always kept ordered by name, and names are unique (with a few very +specific rules) at any point in time, but the cache has no long-term +meaning, and can be partially updated at any time. + +In particular, the index certainly does not need to be consistent with +the current directory contents (in fact, most operations will depend on +different ways to make the index 'not' be consistent with the directory +hierarchy), but it has three very important attributes: + +'(a) it can re-generate the full state it caches (not just the +directory structure: it contains pointers to the "blob" objects so +that it can regenerate the data too)' + +As a special case, there is a clear and unambiguous one-way mapping +from a current directory cache to a "tree object", which can be +efficiently created from just the current directory cache without +actually looking at any other data. So a directory cache at any one +time uniquely specifies one and only one "tree" object (but has +additional data to make it easy to match up that tree object with what +has happened in the directory) + +'(b) it has efficient methods for finding inconsistencies between that +cached state ("tree object waiting to be instantiated") and the +current state.' + +'(c) it can additionally efficiently represent information about merge +conflicts between different tree objects, allowing each pathname to be +associated with sufficient information about the trees involved that +you can create a three-way merge between them.' + +Those are the three ONLY things that the directory cache does. It's a +cache, and the normal operation is to re-generate it completely from a +known tree object, or update/compare it with a live tree that is being +developed. If you blow the directory cache away entirely, you generally +haven't lost any information as long as you have the name of the tree +that it described. + +At the same time, the index is at the same time also the +staging area for creating new trees, and creating a new tree always +involves a controlled modification of the index file. In particular, +the index file can have the representation of an intermediate tree that +has not yet been instantiated. So the index can be thought of as a +write-back cache, which can contain dirty information that has not yet +been written back to the backing store. + + + +The Workflow +------------ + +Generally, all "git" operations work on the index file. Some operations +work *purely* on the index file (showing the current state of the +index), but most operations move data to and from the index file. Either +from the database or from the working directory. Thus there are four +main combinations: + +working directory -> index +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You update the index with information from the working directory with +the gitlink:git-update-index[1] command. You +generally update the index information by just specifying the filename +you want to update, like so: + +------------------------------------------------- +$ git-update-index filename +------------------------------------------------- + +but to avoid common mistakes with filename globbing etc, the command +will not normally add totally new entries or remove old entries, +i.e. it will normally just update existing cache entries. + +To tell git that yes, you really do realize that certain files no +longer exist, or that new files should be added, you +should use the `--remove` and `--add` flags respectively. + +NOTE! A `--remove` flag does 'not' mean that subsequent filenames will +necessarily be removed: if the files still exist in your directory +structure, the index will be updated with their new status, not +removed. The only thing `--remove` means is that update-cache will be +considering a removed file to be a valid thing, and if the file really +does not exist any more, it will update the index accordingly. + +As a special case, you can also do `git-update-index --refresh`, which +will refresh the "stat" information of each index to match the current +stat information. It will 'not' update the object status itself, and +it will only update the fields that are used to quickly test whether +an object still matches its old backing store object. + +index -> object database +~~~~~~~~~~~~~~~~~~~~~~~~ + +You write your current index file to a "tree" object with the program + +------------------------------------------------- +$ git-write-tree +------------------------------------------------- + +that doesn't come with any options - it will just write out the +current index into the set of tree objects that describe that state, +and it will return the name of the resulting top-level tree. You can +use that tree to re-generate the index at any time by going in the +other direction: + +object database -> index +~~~~~~~~~~~~~~~~~~~~~~~~ + +You read a "tree" file from the object database, and use that to +populate (and overwrite - don't do this if your index contains any +unsaved state that you might want to restore later!) your current +index. Normal operation is just + +------------------------------------------------- +$ git-read-tree +------------------------------------------------- + +and your index file will now be equivalent to the tree that you saved +earlier. However, that is only your 'index' file: your working +directory contents have not been modified. + +index -> working directory +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You update your working directory from the index by "checking out" +files. This is not a very common operation, since normally you'd just +keep your files updated, and rather than write to your working +directory, you'd tell the index files about the changes in your +working directory (i.e. `git-update-index`). + +However, if you decide to jump to a new version, or check out somebody +else's version, or just restore a previous tree, you'd populate your +index file with read-tree, and then you need to check out the result +with + +------------------------------------------------- +$ git-checkout-index filename +------------------------------------------------- + +or, if you want to check out all of the index, use `-a`. + +NOTE! git-checkout-index normally refuses to overwrite old files, so +if you have an old version of the tree already checked out, you will +need to use the "-f" flag ('before' the "-a" flag or the filename) to +'force' the checkout. + + +Finally, there are a few odds and ends which are not purely moving +from one representation to the other: + +Tying it all together +~~~~~~~~~~~~~~~~~~~~~ + +To commit a tree you have instantiated with "git-write-tree", you'd +create a "commit" object that refers to that tree and the history +behind it - most notably the "parent" commits that preceded it in +history. + +Normally a "commit" has one parent: the previous state of the tree +before a certain change was made. However, sometimes it can have two +or more parent commits, in which case we call it a "merge", due to the +fact that such a commit brings together ("merges") two or more +previous states represented by other commits. + +In other words, while a "tree" represents a particular directory state +of a working directory, a "commit" represents that state in "time", +and explains how we got there. + +You create a commit object by giving it the tree that describes the +state at the time of the commit, and a list of parents: + +------------------------------------------------- +$ git-commit-tree -p [-p ..] +------------------------------------------------- + +and then giving the reason for the commit on stdin (either through +redirection from a pipe or file, or by just typing it at the tty). + +git-commit-tree will return the name of the object that represents +that commit, and you should save it away for later use. Normally, +you'd commit a new `HEAD` state, and while git doesn't care where you +save the note about that state, in practice we tend to just write the +result to the file pointed at by `.git/HEAD`, so that we can always see +what the last committed state was. + +Here is an ASCII art by Jon Loeliger that illustrates how +various pieces fit together. + +------------ + + commit-tree + commit obj + +----+ + | | + | | + V V + +-----------+ + | Object DB | + | Backing | + | Store | + +-----------+ + ^ + write-tree | | + tree obj | | + | | read-tree + | | tree obj + V + +-----------+ + | Index | + | "cache" | + +-----------+ + update-index ^ + blob obj | | + | | + checkout-index -u | | checkout-index + stat | | blob obj + V + +-----------+ + | Working | + | Directory | + +-----------+ + +------------ + + +Examining the data +------------------ + +You can examine the data represented in the object database and the +index with various helper tools. For every object, you can use +gitlink:git-cat-file[1] to examine details about the +object: + +------------------------------------------------- +$ git-cat-file -t +------------------------------------------------- + +shows the type of the object, and once you have the type (which is +usually implicit in where you find the object), you can use + +------------------------------------------------- +$ git-cat-file blob|tree|commit|tag +------------------------------------------------- + +to show its contents. NOTE! Trees have binary content, and as a result +there is a special helper for showing that content, called +`git-ls-tree`, which turns the binary content into a more easily +readable form. + +It's especially instructive to look at "commit" objects, since those +tend to be small and fairly self-explanatory. In particular, if you +follow the convention of having the top commit name in `.git/HEAD`, +you can do + +------------------------------------------------- +$ git-cat-file commit HEAD +------------------------------------------------- + +to see what the top commit was. + +Merging multiple trees +---------------------- + +Git helps you do a three-way merge, which you can expand to n-way by +repeating the merge procedure arbitrary times until you finally +"commit" the state. The normal situation is that you'd only do one +three-way merge (two parents), and commit it, but if you like to, you +can do multiple parents in one go. + +To do a three-way merge, you need the two sets of "commit" objects +that you want to merge, use those to find the closest common parent (a +third "commit" object), and then use those commit objects to find the +state of the directory ("tree" object) at these points. + +To get the "base" for the merge, you first look up the common parent +of two commits with + +------------------------------------------------- +$ git-merge-base +------------------------------------------------- + +which will return you the commit they are both based on. You should +now look up the "tree" objects of those commits, which you can easily +do with (for example) + +------------------------------------------------- +$ git-cat-file commit | head -1 +------------------------------------------------- + +since the tree object information is always the first line in a commit +object. + +Once you know the three trees you are going to merge (the one "original" +tree, aka the common case, and the two "result" trees, aka the branches +you want to merge), you do a "merge" read into the index. This will +complain if it has to throw away your old index contents, so you should +make sure that you've committed those - in fact you would normally +always do a merge against your last commit (which should thus match what +you have in your current index anyway). + +To do the merge, do + +------------------------------------------------- +$ git-read-tree -m -u +------------------------------------------------- + +which will do all trivial merge operations for you directly in the +index file, and you can just write the result out with +`git-write-tree`. + + +Merging multiple trees, continued +--------------------------------- + +Sadly, many merges aren't trivial. If there are files that have +been added.moved or removed, or if both branches have modified the +same file, you will be left with an index tree that contains "merge +entries" in it. Such an index tree can 'NOT' be written out to a tree +object, and you will have to resolve any such merge clashes using +other tools before you can write out the result. + +You can examine such index state with `git-ls-files --unmerged` +command. An example: + +------------------------------------------------ +$ git-read-tree -m $orig HEAD $target +$ git-ls-files --unmerged +100644 263414f423d0e4d70dae8fe53fa34614ff3e2860 1 hello.c +100644 06fa6a24256dc7e560efa5687fa84b51f0263c3a 2 hello.c +100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c +------------------------------------------------ + +Each line of the `git-ls-files --unmerged` output begins with +the blob mode bits, blob SHA1, 'stage number', and the +filename. The 'stage number' is git's way to say which tree it +came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD` +tree, and stage3 `$target` tree. + +Earlier we said that trivial merges are done inside +`git-read-tree -m`. For example, if the file did not change +from `$orig` to `HEAD` nor `$target`, or if the file changed +from `$orig` to `HEAD` and `$orig` to `$target` the same way, +obviously the final outcome is what is in `HEAD`. What the +above example shows is that file `hello.c` was changed from +`$orig` to `HEAD` and `$orig` to `$target` in a different way. +You could resolve this by running your favorite 3-way merge +program, e.g. `diff3` or `merge`, on the blob objects from +these three stages yourself, like this: + +------------------------------------------------ +$ git-cat-file blob 263414f... >hello.c~1 +$ git-cat-file blob 06fa6a2... >hello.c~2 +$ git-cat-file blob cc44c73... >hello.c~3 +$ merge hello.c~2 hello.c~1 hello.c~3 +------------------------------------------------ + +This would leave the merge result in `hello.c~2` file, along +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 +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 +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 resolve` is implemented with. + +How git stores objects efficiently: pack files +---------------------------------------------- + +We've seen how git stores each object in a file named after the +object's SHA1 hash. + +Unfortunately this system becomes inefficient once a project has a +lot of objects. Try this on an old project: + +------------------------------------------------ +$ git count-objects +6930 objects, 47620 kilobytes +------------------------------------------------ + +The first number is the number of objects which are kept in +individual files. The second is the amount of space taken up by +those "loose" objects. + +You can save space and make git faster by moving these loose objects in +to a "pack file", which stores a group of objects in an efficient +compressed format; the details of how pack files are formatted can be +found in link:technical/pack-format.txt[technical/pack-format.txt]. + +To put the loose objects into a pack, just run git repack: + +------------------------------------------------ +$ git repack +Generating pack... +Done counting 6020 objects. +Deltifying 6020 objects. + 100% (6020/6020) done +Writing 6020 objects. + 100% (6020/6020) done +Total 6020, written 6020 (delta 4070), reused 0 (delta 0) +Pack pack-3e54ad29d5b2e05838c75df582c65257b8d08e1c created. +------------------------------------------------ + +You can then run + +------------------------------------------------ +$ git prune +------------------------------------------------ + +to remove any of the "loose" objects that are now contained in the +pack. This will also remove any unreferenced objects (which may be +created when, for example, you use "git reset" to remove a commit). +You can verify that the loose objects are gone by looking at the +.git/objects directory or by running + +------------------------------------------------ +$ git count-objects +0 objects, 0 kilobytes +------------------------------------------------ + +Although the object files are gone, any commands that refer to those +objects will work exactly as they did before. + +The gitlink:git-gc[1] command performs packing, pruning, and more for +you, so is normally the only high-level command you need. + +[[dangling-objects]] +Dangling objects +---------------- + +The gitlink:git-fsck[1] command will sometimes complain about dangling +objects. They are not a problem. + +The most common cause of dangling objects is that you've rebased a +branch, or you have pulled from somebody else who rebased a branch--see +<>. In that case, the old head of the original +branch still exists, as does obviously everything it pointed to. The +branch pointer itself just doesn't, since you replaced it with another +one. + +There are also other situations too that cause dangling objects. For +example, a "dangling blob" may arise because you did a "git add" of a +file, but then, before you actually committed it and made it part of the +bigger picture, you changed something else in that file and committed +that *updated* thing - the old state that you added originally ends up +not being pointed to by any commit or tree, so it's now a dangling blob +object. + +Similarly, when the "recursive" merge strategy runs, and finds that +there are criss-cross merges and thus more than one merge base (which is +fairly unusual, but it does happen), it will generate one temporary +midway tree (or possibly even more, if you had lots of criss-crossing +merges and more than two merge bases) as a temporary internal merge +base, and again, those are real objects, but the end result will not end +up pointing to them, so they end up "dangling" in your repository. + +Generally, dangling objects aren't anything to worry about. They can +even be very useful: if you screw something up, the dangling objects can +be how you recover your old tree (say, you did a rebase, and realized +that you really didn't want to - you can look at what dangling objects +you have, and decide to reset your head to some old dangling state). + +For commits, the most useful thing to do with dangling objects tends to +be to do a simple + +------------------------------------------------ +$ gitk --not --all +------------------------------------------------ + +For blobs and trees, you can't do the same, but you can examine them. +You can just do + +------------------------------------------------ +$ git show +------------------------------------------------ + +to show what the contents of the blob were (or, for a tree, basically +what the "ls" for that directory was), and that may give you some idea +of what the operation was that left that dangling object. + +Usually, dangling blobs and trees aren't very interesting. They're +almost always the result of either being a half-way mergebase (the blob +will often even have the conflict markers from a merge in it, if you +have had conflicting merges that you fixed up by hand), or simply +because you interrupted a "git fetch" with ^C or something like that, +leaving _some_ of the new objects in the object database, but just +dangling and useless. + +Anyway, once you are sure that you're not interested in any dangling +state, you can just prune all unreachable objects: + +------------------------------------------------ +$ git prune +------------------------------------------------ + +and they'll be gone. But you should only run "git prune" on a quiescent +repository - it's kind of like doing a filesystem fsck recovery: you +don't want to do that while the filesystem is mounted. + +(The same is true of "git-fsck" itself, btw - but since +git-fsck never actually *changes* the repository, it just reports +on what it found, git-fsck itself is never "dangerous" to run. +Running it while somebody is actually changing the repository can cause +confusing and scary messages, but it won't actually do anything bad. In +contrast, running "git prune" while somebody is actively changing the +repository is a *BAD* idea). + +Glossary of git terms +===================== + +include::glossary.txt[] + +Notes and todo list for this manual +=================================== + +This is a work in progress. + +The basic requirements: + - It must be readable in order, from beginning to end, by + someone intelligent with a basic grasp of the unix + commandline, but without any special knowledge of git. If + necessary, any other prerequisites should be specifically + mentioned as they arise. + - Whenever possible, section headings should clearly describe + the task they explain how to do, in language that requires + no more knowledge than necessary: for example, "importing + patches into a project" rather than "the git-am command" + +Think about how to create a clear chapter dependency graph that will +allow people to get to important topics without necessarily reading +everything in between. + +Scan Documentation/ for other stuff left out; in particular: + howto's + some of technical/? + hooks + list of commands in gitlink:git[1] + +Scan email archives for other stuff left out + +Scan man pages to see if any assume more background than this manual +provides. + +Simplify beginning by suggesting disconnected head instead of +temporary branch creation? + +Explain how to refer to file stages in the "how to resolve a merge" +section: diff -1, -2, -3, --ours, --theirs :1:/path notation. The +"git ls-files --unmerged --stage" thing is sorta useful too, +actually. And note gitk --merge. + +Add more good examples. Entire sections of just cookbook examples +might be a good idea; maybe make an "advanced examples" section a +standard end-of-chapter section? + +Include cross-references to the glossary, where appropriate. + +Document shallow clones? See draft 1.5.0 release notes for some +documentation. + +Add a sectin on working with other version control systems, including +CVS, Subversion, and just imports of series of release tarballs. + +More details on gitweb? + +Write a chapter on using plumbing and writing scripts. diff --git a/GIT-VERSION-GEN b/GIT-VERSION-GEN index e0adc340d3..8f266d0859 100755 --- a/GIT-VERSION-GEN +++ b/GIT-VERSION-GEN @@ -1,7 +1,7 @@ #!/bin/sh GVF=GIT-VERSION-FILE -DEF_VER=v1.5.0-rc2.GIT +DEF_VER=v1.5.0-rc3.GIT LF=' ' diff --git a/Makefile b/Makefile index 0aadd413e5..b8fa92ad8b 100644 --- a/Makefile +++ b/Makefile @@ -284,6 +284,7 @@ BUILTIN_OBJS = \ builtin-diff-tree.o \ builtin-fmt-merge-msg.o \ builtin-for-each-ref.o \ + builtin-fsck.o \ builtin-grep.o \ builtin-init-db.o \ builtin-log.o \ diff --git a/builtin-blame.c b/builtin-blame.c index 02bda5e196..3033e9bdad 100644 --- a/builtin-blame.c +++ b/builtin-blame.c @@ -77,6 +77,10 @@ struct origin { char path[FLEX_ARRAY]; }; +/* + * Given an origin, prepare mmfile_t structure to be used by the + * diff machinery + */ static char *fill_origin_blob(struct origin *o, mmfile_t *file) { if (!o->file.ptr) { @@ -91,6 +95,10 @@ static char *fill_origin_blob(struct origin *o, mmfile_t *file) return file->ptr; } +/* + * Origin is refcounted and usually we keep the blob contents to be + * reused. + */ static inline struct origin *origin_incref(struct origin *o) { if (o) @@ -108,6 +116,11 @@ static void origin_decref(struct origin *o) } } +/* + * Each group of lines is described by a blame_entry; it can be split + * as we pass blame to the parents. They form a linked list in the + * scoreboard structure, sorted by the target line number. + */ struct blame_entry { struct blame_entry *prev; struct blame_entry *next; @@ -134,19 +147,24 @@ struct blame_entry { int s_lno; /* how significant this entry is -- cached to avoid - * scanning the lines over and over + * scanning the lines over and over. */ unsigned score; }; +/* + * The current state of the blame assignment. + */ struct scoreboard { /* the final commit (i.e. where we started digging from) */ struct commit *final; const char *path; - /* the contents in the final; pointed into by buf pointers of - * blame_entries + /* + * The contents in the final image. + * Used by many functions to obtain contents of the nth line, + * indexed with scoreboard.lineno[blame_entry.lno]. */ const char *final_buf; unsigned long final_buf_size; @@ -171,6 +189,11 @@ static int cmp_suspect(struct origin *a, struct origin *b) static void sanity_check_refcnt(struct scoreboard *); +/* + * If two blame entries that are next to each other came from + * contiguous lines in the same origin (i.e. pair), + * merge them together. + */ static void coalesce(struct scoreboard *sb) { struct blame_entry *ent, *next; @@ -194,6 +217,12 @@ static void coalesce(struct scoreboard *sb) sanity_check_refcnt(sb); } +/* + * Given a commit and a path in it, create a new origin structure. + * The callers that add blame to the scoreboard should use + * get_origin() to obtain shared, refcounted copy instead of calling + * this function directly. + */ static struct origin *make_origin(struct commit *commit, const char *path) { struct origin *o; @@ -204,6 +233,9 @@ static struct origin *make_origin(struct commit *commit, const char *path) return o; } +/* + * Locate an existing origin or create a new one. + */ static struct origin *get_origin(struct scoreboard *sb, struct commit *commit, const char *path) @@ -218,6 +250,13 @@ static struct origin *get_origin(struct scoreboard *sb, return make_origin(commit, path); } +/* + * Fill the blob_sha1 field of an origin if it hasn't, so that later + * call to fill_origin_blob() can use it to locate the data. blob_sha1 + * for an origin is also used to pass the blame for the entire file to + * the parent to detect the case where a child's blob is identical to + * that of its parent's. + */ static int fill_blob_sha1(struct origin *origin) { unsigned mode; @@ -238,6 +277,10 @@ static int fill_blob_sha1(struct origin *origin) return -1; } +/* + * We have an origin -- check if the same path exists in the + * parent and return an origin structure to represent it. + */ static struct origin *find_origin(struct scoreboard *sb, struct commit *parent, struct origin *origin) @@ -247,12 +290,26 @@ static struct origin *find_origin(struct scoreboard *sb, const char *paths[2]; if (parent->util) { - /* This is a freestanding copy of origin and not - * refcounted. + /* + * Each commit object can cache one origin in that + * commit. This is a freestanding copy of origin and + * not refcounted. */ struct origin *cached = parent->util; if (!strcmp(cached->path, origin->path)) { + /* + * The same path between origin and its parent + * without renaming -- the most common case. + */ porigin = get_origin(sb, parent, cached->path); + + /* + * If the origin was newly created (i.e. get_origin + * would call make_origin if none is found in the + * scoreboard), it does not know the blob_sha1, + * so copy it. Otherwise porigin was in the + * scoreboard and already knows blob_sha1. + */ if (porigin->refcnt == 1) hashcpy(porigin->blob_sha1, cached->blob_sha1); return porigin; @@ -309,7 +366,13 @@ static struct origin *find_origin(struct scoreboard *sb, } diff_flush(&diff_opts); if (porigin) { + /* + * Create a freestanding copy that is not part of + * the refcounted origin found in the scoreboard, and + * cache it in the commit. + */ struct origin *cached; + cached = make_origin(porigin->commit, porigin->path); hashcpy(cached->blob_sha1, porigin->blob_sha1); parent->util = cached; @@ -317,6 +380,10 @@ static struct origin *find_origin(struct scoreboard *sb, return porigin; } +/* + * We have an origin -- find the path that corresponds to it in its + * parent and return an origin structure to represent it. + */ static struct origin *find_rename(struct scoreboard *sb, struct commit *parent, struct origin *origin) @@ -353,6 +420,9 @@ static struct origin *find_rename(struct scoreboard *sb, return porigin; } +/* + * Parsing of patch chunks... + */ struct chunk { /* line number in postimage; up to but not including this * line is the same as preimage @@ -454,6 +524,11 @@ static struct patch *compare_buffer(mmfile_t *file_p, mmfile_t *file_o, return state.ret; } +/* + * Run diff between two origins and grab the patch output, so that + * we can pass blame for lines origin is currently suspected for + * to its parent. + */ static struct patch *get_patch(struct origin *parent, struct origin *origin) { mmfile_t file_p, file_o; @@ -474,6 +549,10 @@ static void free_patch(struct patch *p) free(p); } +/* + * Link in a new blame entry to the scorebord. Entries that cover the + * same line range have been removed from the scoreboard previously. + */ static void add_blame_entry(struct scoreboard *sb, struct blame_entry *e) { struct blame_entry *ent, *prev = NULL; @@ -497,6 +576,12 @@ static void add_blame_entry(struct scoreboard *sb, struct blame_entry *e) e->next->prev = e; } +/* + * src typically is on-stack; we want to copy the information in it to + * an malloced blame_entry that is already on the linked list of the + * scoreboard. The origin of dst loses a refcnt while the origin of src + * gains one. + */ static void dup_entry(struct blame_entry *dst, struct blame_entry *src) { struct blame_entry *p, *n; @@ -516,25 +601,25 @@ static const char *nth_line(struct scoreboard *sb, int lno) return sb->final_buf + sb->lineno[lno]; } +/* + * It is known that lines between tlno to same came from parent, and e + * has an overlap with that range. it also is known that parent's + * line plno corresponds to e's line tlno. + * + * <---- e -----> + * <------> + * <------------> + * <------------> + * <------------------> + * + * Split e into potentially three parts; before this chunk, the chunk + * to be blamed for the parent, and after that portion. + */ static void split_overlap(struct blame_entry *split, struct blame_entry *e, int tlno, int plno, int same, struct origin *parent) { - /* it is known that lines between tlno to same came from - * parent, and e has an overlap with that range. it also is - * known that parent's line plno corresponds to e's line tlno. - * - * <---- e -----> - * <------> - * <------------> - * <------------> - * <------------------> - * - * Potentially we need to split e into three parts; before - * this chunk, the chunk to be blamed for parent, and after - * that portion. - */ int chunk_end_lno; memset(split, 0, sizeof(struct blame_entry [3])); @@ -564,11 +649,20 @@ static void split_overlap(struct blame_entry *split, chunk_end_lno = e->lno + e->num_lines; split[1].num_lines = chunk_end_lno - split[1].lno; + /* + * if it turns out there is nothing to blame the parent for, + * forget about the splitting. !split[1].suspect signals this. + */ if (split[1].num_lines < 1) return; split[1].suspect = origin_incref(parent); } +/* + * split_overlap() divided an existing blame e into up to three parts + * in split. Adjust the linked list of blames in the scoreboard to + * reflect the split. + */ static void split_blame(struct scoreboard *sb, struct blame_entry *split, struct blame_entry *e) @@ -576,21 +670,27 @@ static void split_blame(struct scoreboard *sb, struct blame_entry *new_entry; if (split[0].suspect && split[2].suspect) { - /* we need to split e into two and add another for parent */ + /* The first part (reuse storage for the existing entry e) */ dup_entry(e, &split[0]); + /* The last part -- me */ new_entry = xmalloc(sizeof(*new_entry)); memcpy(new_entry, &(split[2]), sizeof(struct blame_entry)); add_blame_entry(sb, new_entry); + /* ... and the middle part -- parent */ new_entry = xmalloc(sizeof(*new_entry)); memcpy(new_entry, &(split[1]), sizeof(struct blame_entry)); add_blame_entry(sb, new_entry); } else if (!split[0].suspect && !split[2].suspect) - /* parent covers the entire area */ + /* + * The parent covers the entire area; reuse storage for + * e and replace it with the parent. + */ dup_entry(e, &split[1]); else if (split[0].suspect) { + /* me and then parent */ dup_entry(e, &split[0]); new_entry = xmalloc(sizeof(*new_entry)); @@ -598,6 +698,7 @@ static void split_blame(struct scoreboard *sb, add_blame_entry(sb, new_entry); } else { + /* parent and then me */ dup_entry(e, &split[1]); new_entry = xmalloc(sizeof(*new_entry)); @@ -628,6 +729,10 @@ static void split_blame(struct scoreboard *sb, } } +/* + * After splitting the blame, the origins used by the + * on-stack blame_entry should lose one refcnt each. + */ static void decref_split(struct blame_entry *split) { int i; @@ -636,6 +741,10 @@ static void decref_split(struct blame_entry *split) origin_decref(split[i].suspect); } +/* + * Helper for blame_chunk(). blame_entry e is known to overlap with + * the patch hunk; split it and pass blame to the parent. + */ static void blame_overlap(struct scoreboard *sb, struct blame_entry *e, int tlno, int plno, int same, struct origin *parent) @@ -648,6 +757,9 @@ static void blame_overlap(struct scoreboard *sb, struct blame_entry *e, decref_split(split); } +/* + * Find the line number of the last line the target is suspected for. + */ static int find_last_in_target(struct scoreboard *sb, struct origin *target) { struct blame_entry *e; @@ -662,6 +774,11 @@ static int find_last_in_target(struct scoreboard *sb, struct origin *target) return last_in_target; } +/* + * Process one hunk from the patch between the current suspect for + * blame_entry e and its parent. Find and split the overlap, and + * pass blame to the overlapping part to the parent. + */ static void blame_chunk(struct scoreboard *sb, int tlno, int plno, int same, struct origin *target, struct origin *parent) @@ -678,6 +795,11 @@ static void blame_chunk(struct scoreboard *sb, } } +/* + * We are looking at the origin 'target' and aiming to pass blame + * for the lines it is suspected to its parent. Run diff to find + * which lines came from parent and pass blame for them. + */ static int pass_blame_to_parent(struct scoreboard *sb, struct origin *target, struct origin *parent) @@ -698,13 +820,22 @@ static int pass_blame_to_parent(struct scoreboard *sb, plno = chunk->p_next; tlno = chunk->t_next; } - /* rest (i.e. anything above tlno) are the same as parent */ + /* The rest (i.e. anything after tlno) are the same as the parent */ blame_chunk(sb, tlno, plno, last_in_target, target, parent); free_patch(patch); return 0; } +/* + * The lines in blame_entry after splitting blames many times can become + * very small and trivial, and at some point it becomes pointless to + * blame the parents. E.g. "\t\t}\n\t}\n\n" appears everywhere in any + * ordinary C program, and it is not worth to say it was copied from + * totally unrelated file in the parent. + * + * Compute how trivial the lines in the blame_entry are. + */ static unsigned ent_score(struct scoreboard *sb, struct blame_entry *e) { unsigned score; @@ -726,6 +857,12 @@ static unsigned ent_score(struct scoreboard *sb, struct blame_entry *e) return score; } +/* + * best_so_far[] and this[] are both a split of an existing blame_entry + * that passes blame to the parent. Maintain best_so_far the best split + * so far, by comparing this and best_so_far and copying this into + * bst_so_far as needed. + */ static void copy_split_if_better(struct scoreboard *sb, struct blame_entry *best_so_far, struct blame_entry *this) @@ -745,6 +882,11 @@ static void copy_split_if_better(struct scoreboard *sb, memcpy(best_so_far, this, sizeof(struct blame_entry [3])); } +/* + * Find the lines from parent that are the same as ent so that + * we can pass blames to it. file_p has the blob contents for + * the parent. + */ static void find_copy_in_blob(struct scoreboard *sb, struct blame_entry *ent, struct origin *parent, @@ -757,6 +899,9 @@ static void find_copy_in_blob(struct scoreboard *sb, struct patch *patch; int i, plno, tlno; + /* + * Prepare mmfile that contains only the lines in ent. + */ cp = nth_line(sb, ent->lno); file_o.ptr = (char*) cp; cnt = ent->num_lines; @@ -792,6 +937,10 @@ static void find_copy_in_blob(struct scoreboard *sb, free_patch(patch); } +/* + * See if lines currently target is suspected for can be attributed to + * parent. + */ static int find_move_in_parent(struct scoreboard *sb, struct origin *target, struct origin *parent) @@ -826,12 +975,15 @@ static int find_move_in_parent(struct scoreboard *sb, return 0; } - struct blame_list { struct blame_entry *ent; struct blame_entry split[3]; }; +/* + * Count the number of entries the target is suspected for, + * and prepare a list of entry and the best split. + */ static struct blame_list *setup_blame_list(struct scoreboard *sb, struct origin *target, int *num_ents_p) @@ -840,9 +992,6 @@ static struct blame_list *setup_blame_list(struct scoreboard *sb, int num_ents, i; struct blame_list *blame_list = NULL; - /* Count the number of entries the target is suspected for, - * and prepare a list of entry and the best split. - */ for (e = sb->ent, num_ents = 0; e; e = e->next) if (!e->guilty && !cmp_suspect(e->suspect, target)) num_ents++; @@ -856,6 +1005,11 @@ static struct blame_list *setup_blame_list(struct scoreboard *sb, return blame_list; } +/* + * For lines target is suspected for, see if we can find code movement + * across file boundary from the parent commit. porigin is the path + * in the parent we already tried. + */ static int find_copy_in_parent(struct scoreboard *sb, struct origin *target, struct commit *parent, @@ -956,7 +1110,8 @@ static int find_copy_in_parent(struct scoreboard *sb, return retval; } -/* The blobs of origin and porigin exactly match, so everything +/* + * The blobs of origin and porigin exactly match, so everything * origin is suspected for can be blamed on the parent. */ static void pass_whole_blame(struct scoreboard *sb, @@ -1041,7 +1196,7 @@ static void pass_blame(struct scoreboard *sb, struct origin *origin, int opt) } /* - * Optionally run "miff" to find moves in parents' files here. + * Optionally find moves in parents' files. */ if (opt & PICKAXE_BLAME_MOVE) for (i = 0, parent = commit->parents; @@ -1055,7 +1210,7 @@ static void pass_blame(struct scoreboard *sb, struct origin *origin, int opt) } /* - * Optionally run "ciff" to find copies from parents' files here. + * Optionally find copies from parents' files. */ if (opt & PICKAXE_BLAME_COPY) for (i = 0, parent = commit->parents; @@ -1072,6 +1227,9 @@ static void pass_blame(struct scoreboard *sb, struct origin *origin, int opt) origin_decref(parent_origin[i]); } +/* + * Information on commits, used for output. + */ struct commit_info { char *author; @@ -1088,6 +1246,9 @@ struct commit_info char *summary; }; +/* + * Parse author/committer line in the commit object buffer + */ static void get_ac_line(const char *inbuf, const char *what, int bufsz, char *person, char **mail, unsigned long *time, char **tz) @@ -1142,7 +1303,8 @@ static void get_commit_info(struct commit *commit, static char committer_buf[1024]; static char summary_buf[1024]; - /* We've operated without save_commit_buffer, so + /* + * We've operated without save_commit_buffer, so * we now need to populate them for output. */ if (!commit->buffer) { @@ -1182,6 +1344,10 @@ static void get_commit_info(struct commit *commit, summary_buf[len] = 0; } +/* + * To allow LF and other nonportable characters in pathnames, + * they are c-style quoted as needed. + */ static void write_filename_info(const char *path) { printf("filename "); @@ -1189,6 +1355,10 @@ static void write_filename_info(const char *path) putchar('\n'); } +/* + * The blame_entry is found to be guilty for the range. Mark it + * as such, and show it in incremental output. + */ static void found_guilty_entry(struct blame_entry *ent) { if (ent->guilty) @@ -1220,6 +1390,11 @@ static void found_guilty_entry(struct blame_entry *ent) } } +/* + * The main loop -- while the scoreboard has lines whose true origin + * is still unknown, pick one brame_entry, and allow its current + * suspect to pass blames to its parents. + */ static void assign_blame(struct scoreboard *sb, struct rev_info *revs, int opt) { while (1) { @@ -1234,12 +1409,16 @@ static void assign_blame(struct scoreboard *sb, struct rev_info *revs, int opt) if (!suspect) return; /* all done */ + /* + * We will use this suspect later in the loop, + * so hold onto it in the meantime. + */ origin_incref(suspect); commit = suspect->commit; if (!commit->object.parsed) parse_commit(commit); if (!(commit->object.flags & UNINTERESTING) && - !(revs->max_age != -1 && commit->date < revs->max_age)) + !(revs->max_age != -1 && commit->date < revs->max_age)) pass_blame(sb, suspect, opt); else { commit->object.flags |= UNINTERESTING; @@ -1431,6 +1610,10 @@ static void output(struct scoreboard *sb, int option) } } +/* + * To allow quick access to the contents of nth line in the + * final image, prepare an index in the scoreboard. + */ static int prepare_lines(struct scoreboard *sb) { const char *buf = sb->final_buf; @@ -1458,6 +1641,11 @@ static int prepare_lines(struct scoreboard *sb) return sb->num_lines; } +/* + * Add phony grafts for use with -S; this is primarily to + * support git-cvsserver that wants to give a linear history + * to its clients. + */ static int read_ancestry(const char *graft_file) { FILE *fp = fopen(graft_file, "r"); @@ -1475,6 +1663,9 @@ static int read_ancestry(const char *graft_file) return 0; } +/* + * How many columns do we need to show line numbers in decimal? + */ static int lineno_width(int lines) { int i, width; @@ -1484,6 +1675,10 @@ static int lineno_width(int lines) return width; } +/* + * How many columns do we need to show line numbers, authors, + * and filenames? + */ static void find_alignment(struct scoreboard *sb, int *option) { int longest_src_lines = 0; @@ -1522,6 +1717,10 @@ static void find_alignment(struct scoreboard *sb, int *option) max_score_digits = lineno_width(largest_score); } +/* + * For debugging -- origin is refcounted, and this asserts that + * we do not underflow. + */ static void sanity_check_refcnt(struct scoreboard *sb) { int baa = 0; @@ -1543,8 +1742,9 @@ static void sanity_check_refcnt(struct scoreboard *sb) ent->suspect->refcnt = -ent->suspect->refcnt; } for (ent = sb->ent; ent; ent = ent->next) { - /* then pick each and see if they have the the correct - * refcnt. + /* + * ... then pick each and see if they have the the + * correct refcnt. */ int found; struct blame_entry *e; @@ -1574,6 +1774,10 @@ static void sanity_check_refcnt(struct scoreboard *sb) } } +/* + * Used for the command line parsing; check if the path exists + * in the working tree. + */ static int has_path_in_work_tree(const char *path) { struct stat st; @@ -1596,6 +1800,9 @@ static const char *add_prefix(const char *prefix, const char *path) return prefix_path(prefix, strlen(prefix), path); } +/* + * Parsing of (comma separated) one item in the -L option + */ static const char *parse_loc(const char *spec, struct scoreboard *sb, long lno, long begin, long *ret) @@ -1670,6 +1877,9 @@ static const char *parse_loc(const char *spec, } } +/* + * Parsing of -L option + */ static void prepare_blame_range(struct scoreboard *sb, const char *bottomtop, long lno, @@ -1788,7 +1998,8 @@ int cmd_blame(int argc, const char **argv, const char *prefix) if (!blame_copy_score) blame_copy_score = BLAME_DEFAULT_COPY_SCORE; - /* We have collected options unknown to us in argv[1..unk] + /* + * We have collected options unknown to us in argv[1..unk] * which are to be passed to revision machinery if we are * going to do the "bottom" procesing. * @@ -1868,7 +2079,8 @@ int cmd_blame(int argc, const char **argv, const char *prefix) if (final_commit_name) argv[unk++] = final_commit_name; - /* Now we got rev and path. We do not want the path pruning + /* + * Now we got rev and path. We do not want the path pruning * but we may want "bottom" processing. */ argv[unk++] = "--"; /* terminate the rev name */ @@ -1878,7 +2090,8 @@ int cmd_blame(int argc, const char **argv, const char *prefix) setup_revisions(unk, argv, &revs, "HEAD"); memset(&sb, 0, sizeof(sb)); - /* There must be one and only one positive commit in the + /* + * There must be one and only one positive commit in the * revs->pending array. */ for (i = 0; i < revs.pending.nr; i++) { @@ -1899,7 +2112,10 @@ int cmd_blame(int argc, const char **argv, const char *prefix) } if (!sb.final) { - /* "--not A B -- path" without anything positive */ + /* + * "--not A B -- path" without anything positive; + * default to HEAD. + */ unsigned char head_sha1[20]; final_commit_name = "HEAD"; @@ -1909,7 +2125,8 @@ int cmd_blame(int argc, const char **argv, const char *prefix) add_pending_object(&revs, &(sb.final->object), "HEAD"); } - /* If we have bottom, this will mark the ancestors of the + /* + * If we have bottom, this will mark the ancestors of the * bottom commits we would reach while traversing as * uninteresting. */ diff --git a/fsck.c b/builtin-fsck.c similarity index 99% rename from fsck.c rename to builtin-fsck.c index 558f0a6b34..fec1cbd784 100644 --- a/fsck.c +++ b/builtin-fsck.c @@ -571,12 +571,11 @@ static int fsck_cache_tree(struct cache_tree *it) return err; } -int main(int argc, char **argv) +int cmd_fsck(int argc, char **argv, const char *prefix) { int i, heads; track_object_refs = 1; - setup_git_directory(); for (i = 1; i < argc; i++) { const char *arg = argv[i]; diff --git a/builtin-update-index.c b/builtin-update-index.c index 182331d341..1ac613a788 100644 --- a/builtin-update-index.c +++ b/builtin-update-index.c @@ -501,6 +501,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix) for (i = 1 ; i < argc; i++) { const char *path = argv[i]; + const char *p; if (allow_options && *path == '-') { if (!strcmp(path, "--")) { @@ -616,9 +617,12 @@ int cmd_update_index(int argc, const char **argv, const char *prefix) usage(update_index_usage); die("unknown option %s", path); } - update_one(path, prefix, prefix_length); + p = prefix_path(prefix, prefix_length, path); + update_one(p, NULL, 0); if (set_executable_bit) - chmod_path(set_executable_bit, path); + chmod_path(set_executable_bit, p); + if (p < path || p > path + strlen(path)) + free((char*)p); } if (read_from_stdin) { struct strbuf buf; diff --git a/builtin-update-ref.c b/builtin-update-ref.c index 1461937cb9..5ee960bf41 100644 --- a/builtin-update-ref.c +++ b/builtin-update-ref.c @@ -61,10 +61,8 @@ int cmd_update_ref(int argc, const char **argv, const char *prefix) lock = lock_any_ref_for_update(refname, oldval ? oldsha1 : NULL); if (!lock) - return 1; + die("%s: cannot lock the ref", refname); if (write_ref_sha1(lock, sha1, msg) < 0) - return 1; - - /* write_ref_sha1 always unlocks the ref, no need to do it explicitly */ + die("%s: cannot update the ref", refname); return 0; } diff --git a/builtin.h b/builtin.h index 2d39843be0..6b1a8e6f92 100644 --- a/builtin.h +++ b/builtin.h @@ -34,6 +34,7 @@ extern int cmd_diff_tree(int argc, const char **argv, const char *prefix); extern int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix); extern int cmd_for_each_ref(int argc, const char **argv, const char *prefix); extern int cmd_format_patch(int argc, const char **argv, const char *prefix); +extern int cmd_fsck(int argc, const char **argv, const char *prefix); extern int cmd_get_tar_commit_id(int argc, const char **argv, const char *prefix); extern int cmd_grep(int argc, const char **argv, const char *prefix); extern int cmd_help(int argc, const char **argv, const char *prefix); diff --git a/contrib/blameview/blameview.perl b/contrib/blameview/blameview.perl index a55f799f00..5e9a67c123 100755 --- a/contrib/blameview/blameview.perl +++ b/contrib/blameview/blameview.perl @@ -28,7 +28,8 @@ $fileview->get_column(0)->set_spacing(0); $fileview->set_size_request(1024, 768); $fileview->set_rules_hint(1); -open(my $fh, '<', $fn) +my $fh; +open($fh, '-|', "git cat-file blob HEAD:$fn") or die "unable to open $fn: $!"; while(<$fh>) { chomp; diff --git a/git-checkout.sh b/git-checkout.sh index fb40cba275..28e07acc56 100755 --- a/git-checkout.sh +++ b/git-checkout.sh @@ -155,9 +155,9 @@ then detached="$new" if test -n "$oldbranch" then - detach_warn="warning: you are not on ANY branch anymore. -If you meant to create a new branch from this checkout, you may still do -so (now or later) by using -b with the checkout command again. Example: + detach_warn="Note: you are not on any branch and are at commit \"$new_name\" +If you want to create a new branch from this checkout, you may do so +(now or later) by using -b with the checkout command again. Example: git checkout -b " fi elif test -z "$oldbranch" && test -n "$branch" @@ -235,7 +235,7 @@ else saved_err=$? if test "$saved_err" = 0 then - test "$new" = "$old" || git diff-index --name-status "$new" + git diff-index --name-status "$new" fi (exit $saved_err) fi @@ -258,6 +258,12 @@ if [ "$?" -eq 0 ]; then if test -n "$branch" then GIT_DIR="$GIT_DIR" git-symbolic-ref -m "checkout: moving to $branch" HEAD "refs/heads/$branch" + if test -n "$newbranch" + then + echo >&2 "Switched to a new branch \"$branch\"" + else + echo >&2 "Switched to branch \"$branch\"" + fi elif test -n "$detached" then # NEEDSWORK: we would want a command to detach the HEAD diff --git a/git-clone.sh b/git-clone.sh index 1531da52cb..4ddfa774ec 100755 --- a/git-clone.sh +++ b/git-clone.sh @@ -66,48 +66,6 @@ Perhaps git-update-server-info needs to be run there?" rm -f "$GIT_DIR/REMOTE_HEAD" } -# Read git-fetch-pack -k output and store the remote branches. -copy_refs=' -use File::Path qw(mkpath); -use File::Basename qw(dirname); -my $git_dir = $ARGV[0]; -my $use_separate_remote = $ARGV[1]; -my $origin = $ARGV[2]; - -my $branch_top = ($use_separate_remote ? "remotes/$origin" : "heads"); -my $tag_top = "tags"; - -sub store { - my ($sha1, $name, $top) = @_; - $name = "$git_dir/refs/$top/$name"; - mkpath(dirname($name)); - open O, ">", "$name"; - print O "$sha1\n"; - close O; -} - -open FH, "<", "$git_dir/CLONE_HEAD"; -while () { - my ($sha1, $name) = /^([0-9a-f]{40})\s(.*)$/; - next if ($name =~ /\^\173/); - if ($name eq "HEAD") { - open O, ">", "$git_dir/REMOTE_HEAD"; - print O "$sha1\n"; - close O; - next; - } - if ($name =~ s/^refs\/heads\///) { - store($sha1, $name, $branch_top); - next; - } - if ($name =~ s/^refs\/tags\///) { - store($sha1, $name, $tag_top); - next; - } -} -close FH; -' - quiet= local=no use_local=no @@ -165,7 +123,7 @@ while shift upload_pack="--upload-pack=$1" ;; *,--upload-pack=*) - upload_pack=--upload-pack=$(expr "$1" : '-[^=]*=\(.*\)') ;; + upload_pack=--upload-pack=$(expr "z$1" : 'z-[^=]*=\(.*\)') ;; 1,--depth) usage;; *,--depth) shift @@ -332,8 +290,29 @@ test -d "$GIT_DIR/refs/reference-tmp" && rm -fr "$GIT_DIR/refs/reference-tmp" if test -f "$GIT_DIR/CLONE_HEAD" then # Read git-fetch-pack -k output and store the remote branches. - @@PERL@@ -e "$copy_refs" "$GIT_DIR" "$use_separate_remote" "$origin" || - exit + if [ -n "$use_separate_remote" ] + then + branch_top="remotes/$origin" + else + branch_top="heads" + fi + tag_top="tags" + while read sha1 name + do + case "$name" in + *'^{}') + continue ;; + HEAD) + destname="REMOTE_HEAD" ;; + refs/heads/*) + destname="refs/$branch_top/${name#refs/heads/}" ;; + refs/tags/*) + destname="refs/$tag_top/${name#refs/tags/}" ;; + *) + continue ;; + esac + git-update-ref -m "clone: from $repo" "$destname" "$sha1" "" + done < "$GIT_DIR/CLONE_HEAD" fi cd "$D" || exit diff --git a/git-commit.sh b/git-commit.sh index 85c278afab..dc0fc3b679 100755 --- a/git-commit.sh +++ b/git-commit.sh @@ -442,8 +442,11 @@ fi | git-stripspace >"$GIT_DIR"/COMMIT_EDITMSG case "$signoff" in t) + need_blank_before_signoff= + tail -n 1 "$GIT_DIR"/COMMIT_EDITMSG | + grep 'Signed-off-by:' >/dev/null || need_blank_before_signoff=yes { - echo + test -z "$need_blank_before_signoff" || echo git-var GIT_COMMITTER_IDENT | sed -e ' s/>.*/>/ s/^/Signed-off-by: / diff --git a/git-fetch.sh b/git-fetch.sh index c1f6e1e841..357cac28b2 100755 --- a/git-fetch.sh +++ b/git-fetch.sh @@ -37,7 +37,7 @@ do ;; --upl=*|--uplo=*|--uploa=*|--upload=*|\ --upload-=*|--upload-p=*|--upload-pa=*|--upload-pac=*|--upload-pack=*) - exec=--upload-pack=$(expr "$1" : '-[^=]*=\(.*\)') + exec=--upload-pack=$(expr "z$1" : 'z-[^=]*=\(.*\)') shift ;; -f|--f|--fo|--for|--forc|--force) diff --git a/git-ls-remote.sh b/git-ls-remote.sh index e6f574b99b..8ea5c5e816 100755 --- a/git-ls-remote.sh +++ b/git-ls-remote.sh @@ -27,7 +27,7 @@ do shift;; -u=*|--u=*|--up=*|--upl=*|--uplo=*|--uploa=*|--upload=*|\ --upload-=*|--upload-p=*|--upload-pa=*|--upload-pac=*|--upload-pack=*) - exec=--upload-pack=$(expr "$1" : '-[^=]*=\(.*\)') + exec=--upload-pack=$(expr "z$1" : 'z-[^=]*=\(.*\)') shift;; --) shift; break ;; diff --git a/git-parse-remote.sh b/git-parse-remote.sh index 9d269671de..3e783b7b05 100755 --- a/git-parse-remote.sh +++ b/git-parse-remote.sh @@ -183,7 +183,7 @@ canon_refs_list_for_fetch () { done fi case "$remote" in - '') remote=HEAD ;; + '' | HEAD ) remote=HEAD ;; refs/heads/* | refs/tags/* | refs/remotes/*) ;; heads/* | tags/* | remotes/* ) remote="refs/$remote" ;; *) remote="refs/heads/$remote" ;; diff --git a/git-rebase.sh b/git-rebase.sh index 19a9768af1..dac9a47726 100755 --- a/git-rebase.sh +++ b/git-rebase.sh @@ -249,7 +249,8 @@ fi git-update-index --refresh || exit diff=$(git-diff-index --cached --name-status -r HEAD) case "$diff" in -?*) echo "$diff" +?*) echo "cannot rebase: your index is not up-to-date" + echo "$diff" exit 1 ;; esac diff --git a/git-send-email.perl b/git-send-email.perl index 8dc2ee0cf7..6a285bfd21 100755 --- a/git-send-email.perl +++ b/git-send-email.perl @@ -408,7 +408,7 @@ sub unquote_rfc2047 { s/_/ /g; s/=([0-9A-F]{2})/chr(hex($1))/eg; } - return "$_ - unquoted"; + return "$_"; } sub send_message diff --git a/git-tag.sh b/git-tag.sh index 988bf4c6a6..4a0a7b6607 100755 --- a/git-tag.sh +++ b/git-tag.sh @@ -113,8 +113,9 @@ object=$(git-rev-parse --verify --default HEAD "$@") || exit 1 type=$(git-cat-file -t $object) || exit 1 tagger=$(git-var GIT_COMMITTER_IDENT) || exit 1 -keyid=$(git-repo-config user.signingkey) || - keyid=$(expr "z$tagger" : 'z\(.*>\)') +test -n "$username" || + username=$(git-repo-config user.signingkey) || + username=$(expr "z$tagger" : 'z\(.*>\)') trap 'rm -f "$GIT_DIR"/TAG_TMP* "$GIT_DIR"/TAG_FINALMSG "$GIT_DIR"/TAG_EDITMSG' 0 @@ -141,7 +142,7 @@ if [ "$annotate" ]; then cat "$GIT_DIR"/TAG_FINALMSG ) >"$GIT_DIR"/TAG_TMP rm -f "$GIT_DIR"/TAG_TMP.asc "$GIT_DIR"/TAG_FINALMSG if [ "$signed" ]; then - gpg -bsa -u "$keyid" "$GIT_DIR"/TAG_TMP && + gpg -bsa -u "$username" "$GIT_DIR"/TAG_TMP && cat "$GIT_DIR"/TAG_TMP.asc >>"$GIT_DIR"/TAG_TMP || die "failed to sign the tag with GPG." fi diff --git a/git.c b/git.c index d5d044feaf..71c8a64a3c 100644 --- a/git.c +++ b/git.c @@ -239,6 +239,8 @@ static void handle_internal_command(int argc, const char **argv, char **envp) { "fmt-merge-msg", cmd_fmt_merge_msg, RUN_SETUP }, { "for-each-ref", cmd_for_each_ref, RUN_SETUP }, { "format-patch", cmd_format_patch, RUN_SETUP }, + { "fsck", cmd_fsck, RUN_SETUP }, + { "fsck-objects", cmd_fsck, RUN_SETUP }, { "get-tar-commit-id", cmd_get_tar_commit_id }, { "grep", cmd_grep, RUN_SETUP }, { "help", cmd_help }, diff --git a/refs.c b/refs.c index 477ce295af..ccc1d6461b 100644 --- a/refs.c +++ b/refs.c @@ -663,6 +663,8 @@ struct ref_lock *lock_ref_sha1(const char *ref, const unsigned char *old_sha1) struct ref_lock *lock_any_ref_for_update(const char *ref, const unsigned char *old_sha1) { + if (check_ref_format(ref) == -1) + return NULL; return lock_ref_sha1_basic(ref, old_sha1, NULL); } diff --git a/server-info.c b/server-info.c index 6cd38be329..f9be5a7f60 100644 --- a/server-info.c +++ b/server-info.c @@ -10,6 +10,8 @@ static FILE *info_ref_fp; static int add_info_ref(const char *path, const unsigned char *sha1, int flag, void *cb_data) { struct object *o = parse_object(sha1); + if (!o) + return -1; fprintf(info_ref_fp, "%s %s\n", sha1_to_hex(sha1), path); if (o->type == OBJ_TAG) { diff --git a/t/t9200-git-cvsexportcommit.sh b/t/t9200-git-cvsexportcommit.sh index fd0a5549fe..c443f32fce 100755 --- a/t/t9200-git-cvsexportcommit.sh +++ b/t/t9200-git-cvsexportcommit.sh @@ -169,19 +169,19 @@ test_expect_success \ test "$(echo $(sort "G g/CVS/Entries"|cut -d/ -f2,3,5))" = "with spaces.png/1.2/-kb with spaces.txt/1.2/" )' -# This test contains ISO-8859-1 characters +# This test contains UTF-8 characters test_expect_success \ 'File with non-ascii file name' \ - 'mkdir -p Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö && - echo Foo >Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/gårdetsågårdet.txt && - git add Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/gårdetsågårdet.txt && - cp ../test9200a.png Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/gårdetsågårdet.png && - git add Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/gårdetsågårdet.png && - git commit -a -m "Går det så går det" && \ + 'mkdir -p Ã…/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/Ã¥/ä/ö && + echo Foo >Ã…/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/Ã¥/ä/ö/gÃ¥rdetsÃ¥gÃ¥rdet.txt && + git add Ã…/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/Ã¥/ä/ö/gÃ¥rdetsÃ¥gÃ¥rdet.txt && + cp ../test9200a.png Ã…/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/Ã¥/ä/ö/gÃ¥rdetsÃ¥gÃ¥rdet.png && + git add Ã…/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/Ã¥/ä/ö/gÃ¥rdetsÃ¥gÃ¥rdet.png && + git commit -a -m "GÃ¥r det sÃ¥ gÃ¥r det" && \ id=$(git rev-list --max-count=1 HEAD) && (cd "$CVSWORK" && git-cvsexportcommit -v -c $id && - test "$(echo $(sort Å/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/å/ä/ö/CVS/Entries|cut -d/ -f2,3,5))" = "gårdetsågårdet.png/1.1/-kb gårdetsågårdet.txt/1.1/" + test "$(echo $(sort Ã…/goo/a/b/c/d/e/f/g/h/i/j/k/l/m/n/o/p/q/r/s/t/u/v/w/x/y/z/Ã¥/ä/ö/CVS/Entries|cut -d/ -f2,3,5))" = "gÃ¥rdetsÃ¥gÃ¥rdet.png/1.1/-kb gÃ¥rdetsÃ¥gÃ¥rdet.txt/1.1/" )' test_expect_success \ @@ -197,6 +197,10 @@ test_expect_success \ ! git-cvsexportcommit -c $id )' +case "$(git repo-config --bool core.filemode)" in +false) + ;; +*) test_expect_success \ 'Retain execute bit' \ 'mkdir G && @@ -211,5 +215,7 @@ test_expect_success \ test -x G/on && ! test -x G/off )' + ;; +esac test_done