Alexander Gavrilov <angavrilov@gmail.com>
Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Brian M. Carlson <sandals@crustytoothpaste.ath.cx>
+Cheng Renquan <crquan@gmail.com>
Chris Shoemaker <c.shoemaker@cox.net>
+Dan Johnson <computerdruid@gmail.com>
Dana L. How <danahow@gmail.com>
Dana L. How <how@deathvalley.cswitch.com>
Daniel Barkalow <barkalow@iabervon.org>
David S. Miller <davem@davemloft.net>
Deskin Miller <deskinm@umich.edu>
Dirk Süsserott <newsletter@dirk.my1.cc>
+Eric S. Raymond <esr@thyrsus.com>
Erik Faye-Lund <kusmabite@gmail.com> <kusmabite@googlemail.com>
Fredrik Kuivinen <freku045@student.liu.se>
+Frédéric Heitzmann <frederic.heitzmann@gmail.com>
H. Peter Anvin <hpa@bonde.sc.orionmulti.com>
H. Peter Anvin <hpa@tazenda.sc.orionmulti.com>
H. Peter Anvin <hpa@trantor.hos.anvin.org>
Horst H. von Brand <vonbrand@inf.utfsm.cl>
İsmail Dönmez <ismail@pardus.org.tr>
+Jakub Narębski <jnareb@gmail.com>
Jay Soffian <jaysoffian+git@gmail.com>
+Jeff King <peff@peff.net> <peff@github.com>
Joachim Berdal Haga <cjhaga@fys.uio.no>
Johannes Sixt <j6t@kdbg.org> <johannes.sixt@telecom.at>
Johannes Sixt <j6t@kdbg.org> <j.sixt@viscovery.net>
Junio C Hamano <gitster@pobox.com> <junio@kernel.org>
Junio C Hamano <gitster@pobox.com> <junkio@cox.net>
Karl Hasselström <kha@treskal.com>
+Kevin Leung <kevinlsk@gmail.com>
Kent Engstrom <kent@lysator.liu.se>
Lars Doelle <lars.doelle@on-line ! de>
Lars Doelle <lars.doelle@on-line.de>
Li Hong <leehong@pku.edu.cn>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@woody.linux-foundation.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@osdl.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@g5.osdl.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@evo.osdl.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@ppc970.osdl.org>
+Linus Torvalds <torvalds@linux-foundation.org> <torvalds@ppc970.osdl.org.(none)>
Lukas Sandström <lukass@etek.chalmers.se>
-Martin Langhoff <martin@laptop.org>
+Marc-André Lureau <marcandre.lureau@gmail.com>
+Mark Rada <marada@uwaterloo.ca>
+Martin Langhoff <martin@laptop.org> <martin@catalyst.net.nz>
Martin von Zweigbergk <martinvonz@gmail.com> <martin.von.zweigbergk@gmail.com>
Michael Coleman <tutufan@gmail.com>
Michael J Gruber <git@drmicha.warpmail.net> <michaeljgruber+gmane@fastmail.fm>
Ramsay Allan Jones <ramsay@ramsay1.demon.co.uk>
René Scharfe <rene.scharfe@lsrfire.ath.cx>
Robert Fitzsimons <robfitz@273k.net>
+Robert Zeh <robert.a.zeh@gmail.com>
Sam Vilain <sam@vilain.net>
Santi Béjar <sbejar@gmail.com>
Sean Estabrooks <seanlkml@sympatico.ca>
Shawn O. Pearce <spearce@spearce.org>
Steven Grimm <koreth@midwinter.com>
+Tay Ray Chuan <rctay89@gmail.com>
Theodore Ts'o <tytso@mit.edu>
Thomas Rast <trast@inf.ethz.ch> <trast@student.ethz.ch>
Tony Luck <tony.luck@intel.com>
- We try to keep to at most 80 characters per line.
+ - We try to support a wide range of C compilers to compile git with,
+ including old ones. That means that you should not use C99
+ initializers, even if a lot of compilers grok it.
+
+ - Variables have to be declared at the beginning of the block.
+
+ - NULL pointers shall be written as NULL, not as 0.
+
- When declaring pointers, the star sides with the variable
name, i.e. "char *string", not "char* string" or
"char * string". This makes it easier to understand code
SP_ARTICLES += howto/revert-branch-rebase
SP_ARTICLES += howto/using-merge-subtree
SP_ARTICLES += howto/using-signed-tag-in-pull-request
+SP_ARTICLES += howto/use-git-daemon
+SP_ARTICLES += howto/update-hook-example
+SP_ARTICLES += howto/setup-git-server-over-http
+SP_ARTICLES += howto/separating-topic-branches
+SP_ARTICLES += howto/revert-a-faulty-merge
+SP_ARTICLES += howto/recover-corrupted-blob-object
+SP_ARTICLES += howto/rebuild-from-update-hook
+SP_ARTICLES += howto/rebuild-from-update-hook
+SP_ARTICLES += howto/rebase-from-internal-branch
+SP_ARTICLES += howto/maintain-git
API_DOCS = $(patsubst %.txt,%,$(filter-out technical/api-index-skel.txt technical/api-index.txt, $(wildcard technical/api-*.txt)))
SP_ARTICLES += $(API_DOCS)
+
+TECH_DOCS = technical/index-format
+TECH_DOCS += technical/pack-format
+TECH_DOCS += technical/pack-heuristics
+TECH_DOCS += technical/pack-protocol
+TECH_DOCS += technical/protocol-capabilities
+TECH_DOCS += technical/protocol-common
+TECH_DOCS += technical/racy-git
+TECH_DOCS += technical/send-pack-pipeline
+TECH_DOCS += technical/shallow
+TECH_DOCS += technical/trivial-merge
+SP_ARTICLES += $(TECH_DOCS)
SP_ARTICLES += technical/api-index
DOC_HTML += $(patsubst %,%.html,$(ARTICLES) $(SP_ARTICLES))
$(RM) *.texi *.texi+ *.texi++ git.info gitman.info
$(RM) *.pdf
$(RM) howto-index.txt howto/*.html doc.dep
- $(RM) technical/api-*.html technical/api-index.txt
+ $(RM) technical/*.html technical/api-index.txt
$(RM) $(cmds_txt) *.made
$(RM) manpage-base-url.xsl
$(QUIET_GEN)cd technical && '$(SHELL_PATH_SQ)' ./api-index.sh
technical/%.html: ASCIIDOC_EXTRA += -a git-relative-html-prefix=../
-$(patsubst %,%.html,$(API_DOCS) technical/api-index): %.html : %.txt
+$(patsubst %,%.html,$(API_DOCS) technical/api-index $(TECH_DOCS)): %.html : %.txt
$(QUIET_ASCIIDOC)$(ASCIIDOC) -b xhtml11 -f asciidoc.conf \
$(ASCIIDOC_EXTRA) -agit_version=$(GIT_VERSION) $*.txt
howto-index.txt: howto-index.sh $(wildcard howto/*.txt)
$(QUIET_GEN)$(RM) $@+ $@ && \
- '$(SHELL_PATH_SQ)' ./howto-index.sh $(wildcard howto/*.txt) >$@+ && \
+ '$(SHELL_PATH_SQ)' ./howto-index.sh $(sort $(wildcard howto/*.txt)) >$@+ && \
mv $@+ $@
$(patsubst %,%.html,$(ARTICLES)) : %.html : %.txt
- the first line of the commit message should be a short
description (50 characters is the soft limit, see DISCUSSION
in git-commit(1)), and should skip the full stop
+ - it is also conventional in most cases to prefix the
+ first line with "area: " where the area is a filename
+ or identifier for the general area of the code being
+ modified, e.g.
+ . archive: ustar header checksum is computed unsigned
+ . git-cherry-pick.txt: clarify the use of revision range notation
+ (if in doubt which identifier to use, run "git log --no-merges"
+ on the files you are modifying to see the current conventions)
- the body should provide a meaningful commit message, which:
. explains the problem the change tries to solve, iow, what
is wrong with the current code without the change.
run git diff --check on your changes before you commit.
-(1a) Try to be nice to older C compilers
-
-We try to support a wide range of C compilers to compile
-git with. That means that you should not use C99 initializers, even
-if a lot of compilers grok it.
-
-Also, variables have to be declared at the beginning of the block
-(you can check this with gcc, using the -Wdeclaration-after-statement
-option).
-
-Another thing: NULL pointers shall be written as NULL, not as 0.
-
-
(2) Generate your patch using git tools out of your commits.
git based diff tools generate unidiff which is the preferred format.
difftool.prompt::
Prompt before each invocation of the diff tool.
-diff.wordRegex::
- A POSIX Extended Regular Expression used to determine what is a "word"
- when performing word-by-word difference calculations. Character
- sequences that match the regular expression are "words", all other
- characters are *ignorable* whitespace.
-
fetch.recurseSubmodules::
This option can be either set to a boolean value or to 'on-demand'.
Setting it to a boolean changes the behavior of fetch and pull to
A boolean to inhibit the standard behavior of printing a space
before each empty output line. Defaults to false.
+diff.wordRegex::
+ A POSIX Extended Regular Expression used to determine what is a "word"
+ when performing word-by-word difference calculations. Character
+ sequences that match the regular expression are "words", all other
+ characters are *ignorable* whitespace.
+
diff.<driver>.command::
The custom diff driver command. See linkgit:gitattributes[5]
for details.
index (i.e. amount of addition/deletions compared to the
file's size). For example, `-M90%` means git should consider a
delete/add pair to be a rename if more than 90% of the file
- hasn't changed.
+ hasn't changed. Without a `%` sign, the number is to be read as
+ a fraction, with a decimal point before it. I.e., `-M5` becomes
+ 0.5, and is thus the same as `-M50%`. Similarly, `-M05` is
+ the same as `-M5%`. To limit detection to exact renames, use
+ `-M100%`.
-C[<n>]::
--find-copies[=<n>]::
ifndef::git-pull[]
-t::
--tags::
- Most of the tags are fetched automatically as branch
- heads are downloaded, but tags that do not point at
- objects reachable from the branch heads that are being
- tracked will not be fetched by this mechanism. This
- flag lets all tags and their associated objects be
- downloaded. The default behavior for a remote may be
- specified with the remote.<name>.tagopt setting. See
- linkgit:git-config[1].
+ This is a short-hand for giving "refs/tags/*:refs/tags/*"
+ refspec from the command line, to ask all tags to be fetched
+ and stored locally. Because this acts as an explicit
+ refspec, the default refspecs (configured with the
+ remote.$name.fetch variable) are overridden and not used.
--recurse-submodules[=yes|on-demand|no]::
This option controls if and under what conditions new commits of
Linux 2.6.26-rc1
-:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile
+:100644 100644 5cf82581... 4492984e... M Makefile
-------------
At this point we can see what the commit does, check it out (if it's
Linux 2.6.26-rc1
-:100644 100644 5cf8258195331a4dbdddff08b8d68642638eea57 4492984efc09ab72ff6219a7bc21fb6a957c4cd5 M Makefile
+:100644 100644 5cf82581... 4492984e... M Makefile
bisect run success
-------------
also update `HEAD` to set the specified branch as the current
branch.
-'git checkout' [<branch>]::
+'git checkout' <branch>::
+ To prepare for working on <branch>, switch to it by updating
+ the index and the files in the working tree, and by pointing
+ HEAD at the branch. Local modifications to the files in the
+ working tree are kept, so that they can be committed to the
+ <branch>.
++
+If <branch> is not found but there does exist a tracking branch in
+exactly one remote (call it <remote>) with a matching name, treat as
+equivalent to
++
+------------
+$ git checkout -b <branch> --track <remote>/<branch>
+------------
++
+You could omit <branch>, in which case the command degenerates to
+"check out the current branch", which is a glorified no-op with a
+rather expensive side-effects to show only the tracking information,
+if exists, for the current branch.
+
'git checkout' -b|-B <new_branch> [<start point>]::
-'git checkout' [--detach] [<commit>]::
- This form switches branches by updating the index, working
- tree, and HEAD to reflect the specified branch or commit.
-+
-If `-b` is given, a new branch is created as if linkgit:git-branch[1]
-were called and then checked out; in this case you can
-use the `--track` or `--no-track` options, which will be passed to
-'git branch'. As a convenience, `--track` without `-b` implies branch
-creation; see the description of `--track` below.
+ Specifying `-b` causes a new branch to be created as if
+ linkgit:git-branch[1] were called and then checked out. In
+ this case you can use the `--track` or `--no-track` options,
+ which will be passed to 'git branch'. As a convenience,
+ `--track` without `-b` implies branch creation; see the
+ description of `--track` below.
+
If `-B` is given, <new_branch> is created if it doesn't exist; otherwise, it
is reset. This is the transactional equivalent of
that is to say, the branch is not reset/created unless "git checkout" is
successful.
+'git checkout' --detach [<branch>]::
+'git checkout' <commit>::
+
+ Prepare to work on top of <commit>, by detaching HEAD at it
+ (see "DETACHED HEAD" section), and updating the index and the
+ files in the working tree. Local modifications to the files
+ in the working tree are kept, so that the resulting working
+ tree will be the state recorded in the commit plus the local
+ modifications.
++
+Passing `--detach` forces this behavior in the case of a <branch> (without
+the option, giving a branch name to the command would check out the branch,
+instead of detaching HEAD at it), or the current commit,
+if no <branch> is specified.
+
'git checkout' [-p|--patch] [<tree-ish>] [--] <pathspec>...::
When <paths> or `--patch` are given, 'git checkout' does *not*
[-F <file> | -m <msg>] [--reset-author] [--allow-empty]
[--allow-empty-message] [--no-verify] [-e] [--author=<author>]
[--date=<date>] [--cleanup=<mode>] [--status | --no-status]
- [-i | -o] [--] [<file>...]
+ [-i | -o] [-S[<keyid>]] [--] [<file>...]
DESCRIPTION
-----------
commit message template when using an editor to prepare the
default commit message.
+-S[<keyid>]::
+--gpg-sign[=<keyid>]::
+ GPG-sign commit.
+
\--::
Do not interpret any more arguments as options.
'git diff' [options] [<commit>] [--] [<path>...]
'git diff' [options] --cached [<commit>] [--] [<path>...]
'git diff' [options] <commit> <commit> [--] [<path>...]
+'git diff' [options] <blob> <blob>
'git diff' [options] [--no-index] [--] <path> <path>
DESCRIPTION
This is to view the changes between two arbitrary
<commit>.
+'git diff' [options] <blob> <blob>::
+
+ This form is to view the differences between the raw
+ contents of two blob objects.
+
'git diff' [--options] <commit>..<commit> [--] [<path>...]::
This is synonymous to the previous form. If <commit> on
Just in case if you are doing something exotic, it should be
noted that all of the <commit> in the above description, except
in the last two forms that use ".." notations, can be any
-<tree>. The third form ('git diff <commit> <commit>') can also
-be used to compare two <blob> objects.
+<tree>.
For a more complete list of ways to spell <commit>, see
"SPECIFYING REVISIONS" section in linkgit:gitrevisions[7].
SYNOPSIS
--------
[verse]
-'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag] [--upload-pack=<git-upload-pack>] [--depth=<n>] [--no-progress] [-v] [<host>:]<directory> [<refs>...]
+'git fetch-pack' [--all] [--quiet|-q] [--keep|-k] [--thin] [--include-tag]
+ [--upload-pack=<git-upload-pack>]
+ [--depth=<n>] [--no-progress]
+ [-v] [<host>:]<directory> [<refs>...]
DESCRIPTION
-----------
neighborhood maintainer is struck down by a wayward bus. Out of the
hordes of suckers (loyal developers), you have been tricked (chosen) to
step up as the new maintainer. This howto will show you "how to" do it.
+Content-type: text/asciidoc
+
+How to maintain Git
+===================
The maintainer's git time is spent on three activities.
the "master" branch, and how "rebase" works. Also discussed
is how this applies to individual developers who sends patches
upstream.
+Content-type: text/asciidoc
+How to rebase from an internal branch
+=====================================
+
+--------------------------------------
Petr Baudis <pasky@suse.cz> writes:
> Dear diary, on Sun, Aug 14, 2005 at 09:57:13AM CEST, I got a letter
>> > branch to the real branches.
>>
> Actually, wouldn't this be also precisely for what StGIT is intended to?
+--------------------------------------
Exactly my feeling. I was sort of waiting for Catalin to speak
up. With its basing philosophical ancestry on quilt, this is
the #1' commit.
-jc
-
--
-To unsubscribe from this list: send the line "unsubscribe git" in
-the body of a message to majordomo@vger.kernel.org
-More majordomo info at http://vger.kernel.org/majordomo-info.html
Abstract: In this how-to article, JC talks about how he
uses the post-update hook to automate git documentation page
shown at http://www.kernel.org/pub/software/scm/git/docs/.
+Content-type: text/asciidoc
+
+How to rebuild from update hook
+===============================
The pages under http://www.kernel.org/pub/software/scm/git/docs/
are built from Documentation/ directory of the git.git project
Subject: corrupt object on git-gc
Abstract: Some tricks to reconstruct blob objects in order to fix
a corrupted repository.
+Content-type: text/asciidoc
+How to recover a corrupted blob object
+======================================
+
+-----------------------------------------------------------
On Fri, 9 Nov 2007, Yossi Leybovich wrote:
>
> Did not help still the repository look for this object?
> Any one know how can I track this object and understand which file is it
+-----------------------------------------------------------
So exactly *because* the SHA1 hash is cryptographically secure, the hash
itself doesn't actually tell you anything, in order to fix a corrupt
interesting for the future, in the hope that you can re-create a
non-corrupt version.
+-----------------------------------------------------------
So:
> ib]$ mv .git/objects/4b/9458b3786228369c63936db65827de3cc06200 ../
+-----------------------------------------------------------
This is the right thing to do, although it's usually best to save it under
it's full SHA1 name (you just dropped the "4b" from the result ;).
Let's see what that tells us:
+-----------------------------------------------------------
> ib]$ git-fsck --full
> broken link from tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
> to blob 4b9458b3786228369c63936db65827de3cc06200
> missing blob 4b9458b3786228369c63936db65827de3cc06200
+-----------------------------------------------------------
Ok, I removed the "dangling commit" messages, because they are just
messages about the fact that you probably have rebased etc, so they're not
after the offending branch is fixed.
Message-ID: <7vocz8a6zk.fsf@gitster.siamese.dyndns.org>
References: <alpine.LFD.2.00.0812181949450.14014@localhost.localdomain>
+Content-type: text/asciidoc
+
+How to revert a faulty merge
+============================
Alan <alan@clueserver.org> said:
Content-type: text/asciidoc
Message-ID: <7voe7g3uop.fsf@assigned-by-dhcp.cox.net>
-Reverting an existing commit
-============================
+How to revert an existing commit
+================================
One of the changes I pulled into the 'master' branch turns out to
break building GIT with GCC 2.95. While they were well intentioned
From: Junio C Hamano <gitster@pobox.com>
Subject: Separating topic branches
Abstract: In this article, JC describes how to separate topic branches.
+Content-type: text/asciidoc
+
+How to separate topic branches
+==============================
This text was originally a footnote to a discussion about the
behaviour of the git diff commands.
From: Rutger Nijlunsing <rutger@nospam.com>
Subject: Setting up a git repository which can be pushed into and pulled from over HTTP(S).
Date: Thu, 10 Aug 2006 22:00:26 +0200
+Content-type: text/asciidoc
+
+How to setup git server over http
+=================================
Since Apache is one of those packages people like to compile
themselves while others prefer the bureaucrat's dream Debian, it is
Abstract: An example hooks/update script is presented to
implement repository maintenance policies, such as who can push
into which branch and who can make a tag.
+Content-type: text/asciidoc
+
+How to use the update hook
+==========================
When your developer runs git-push into the repository,
git-receive-pack is run (either locally or over ssh) as that
[jc: editorial note. This is a much improved version by Carl
since I posted the original outline]
--- >8 -- beginning of script -- >8 --
-
+----------------------------------------------------
#!/bin/bash
umask 002
info "Found matching head pattern: '$head_pattern'"
for user_pattern in $user_patterns; do
- info "Checking user: '$username' against pattern: '$user_pattern'"
- matchlen=$(expr "$username" : "$user_pattern")
- if test "$matchlen" = "${#username}"
- then
- grant "Allowing user: '$username' with pattern: '$user_pattern'"
- fi
+ info "Checking user: '$username' against pattern: '$user_pattern'"
+ matchlen=$(expr "$username" : "$user_pattern")
+ if test "$matchlen" = "${#username}"
+ then
+ grant "Allowing user: '$username' with pattern: '$user_pattern'"
+ fi
done
deny "The user is not in the access list for this branch"
done
info "Found matching head pattern: '$head_pattern'"
for group_pattern in $group_patterns; do
- for groupname in $groups; do
- info "Checking group: '$groupname' against pattern: '$group_pattern'"
- matchlen=$(expr "$groupname" : "$group_pattern")
- if test "$matchlen" = "${#groupname}"
- then
- grant "Allowing group: '$groupname' with pattern: '$group_pattern'"
- fi
+ for groupname in $groups; do
+ info "Checking group: '$groupname' against pattern: '$group_pattern'"
+ matchlen=$(expr "$groupname" : "$group_pattern")
+ if test "$matchlen" = "${#groupname}"
+ then
+ grant "Allowing group: '$groupname' with pattern: '$group_pattern'"
+ fi
done
done
deny "None of the user's groups are in the access list for this branch"
fi
deny >/dev/null "There are no more rules to check. Denying access"
-
--- >8 -- end of script -- >8 --
+----------------------------------------------------
This uses two files, $GIT_DIR/info/allowed-users and
allowed-groups, to describe which heads can be pushed into by
whom. The format of each file would look like this:
- refs/heads/master junio
- +refs/heads/pu junio
- refs/heads/cogito$ pasky
- refs/heads/bw/.* linus
- refs/heads/tmp/.* .*
- refs/tags/v[0-9].* junio
+ refs/heads/master junio
+ +refs/heads/pu junio
+ refs/heads/cogito$ pasky
+ refs/heads/bw/.* linus
+ refs/heads/tmp/.* .*
+ refs/tags/v[0-9].* junio
With this, Linus can push or create "bw/penguin" or "bw/zebra"
or "bw/panda" branches, Pasky can do only "cogito", and JC can
do master and pu branches and make versioned tags. And anybody
can do tmp/blah branches. The '+' sign at the pu record means
that JC can make non-fast-forward pushes on it.
-
-------------
+Content-type: text/asciidoc
+
How to use git-daemon
+=====================
Git can be run in inetd mode and in stand alone mode. But all you want is
let a coworker pull from you, and therefore need to set up a git server
later validate it.
Content-type: text/asciidoc
-Using signed tag in pull requests
-=================================
+How to use a signed tag in pull requests
+========================================
A typical distributed workflow using Git is for a contributor to fork a
project, build on it, publish the result to her public repository, and ask
////////////////////////////////////////////////////////////////
// table of contents end
////////////////////////////////////////////////////////////////
-
-2007-11-24
GIT index format
================
-= The git index file has the following format
+== The git index file has the following format
All binary numbers are in network byte order. Version 2 is described
here unless stated otherwise.
this span of index as a tree.
An entry can be in an invalidated state and is represented by having
- -1 in the entry_count field. In this case, there is no object name
- and the next entry starts immediately after the newline.
+ a negative number in the entry_count field. In this case, there is no
+ object name and the next entry starts immediately after the newline.
+ When writing an invalid entry, -1 should always be used as entry_count.
The entries are written out in the top-down, depth-first order. The
first entry represents the root level of the repository, followed by the
GIT pack format
===============
-= pack-*.pack files have the following format:
+== pack-*.pack files have the following format:
- A header appears at the beginning and consists of the following:
- The trailer records 20-byte SHA1 checksum of all of the above.
-= Original (version 1) pack-*.idx files have the following format:
+== Original (version 1) pack-*.idx files have the following format:
- The header consists of 256 4-byte network byte order
integers. N-th entry of this table records the number of
-= Version 2 pack-*.idx files support packs larger than 4 GiB, and
- have some other reorganizations. They have the format:
+== Version 2 pack-*.idx files support packs larger than 4 GiB, and
+ have some other reorganizations. They have the format:
- A 4-byte magic number '\377tOc' which is an unreasonable
fanout[0] value.
- The repository path is always quoted with single quotes.
Fetching Data From a Server
-===========================
+---------------------------
When one Git repository wants to get data that a second repository
has, the first can 'fetch' from the second. This operation determines
$ echo -e -n "0039git-upload-pack /schacon/gitbook.git\0host=example.com\0" |
nc -v example.com 9418
- 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag
+ 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack thin-pack
+ side-band side-band-64k ofs-delta shallow no-progress include-tag
00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration
003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master
003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9
Pushing Data To a Server
-========================
+------------------------
Pushing data to a server will invoke the 'receive-pack' process on the
server, which will allow the client to tell it which references it should
-git-send-pack
-=============
+Git-send-pack internals
+=======================
Overall operation
-----------------
-Def.: Shallow commits do have parents, but not in the shallow
+Shallow commits
+===============
+
+.Definition
+*********************************************************
+Shallow commits do have parents, but not in the shallow
repo, and therefore grafts are introduced pretending that
these commits have no parents.
+*********************************************************
The basic idea is to write the SHA1s of shallow commits into
$GIT_DIR/shallow, and handle its contents like the contents
only one ancestor or remote fits; a '^' means all of the ancestors
must be the same.
-case ancest head remote result
-----------------------------------------
-1 (empty)+ (empty) (empty) (empty)
-2ALT (empty)+ *empty* remote remote
-2 (empty)^ (empty) remote no merge
-3ALT (empty)+ head *empty* head
-3 (empty)^ head (empty) no merge
-4 (empty)^ head remote no merge
-5ALT * head head head
-6 ancest+ (empty) (empty) no merge
-8 ancest^ (empty) ancest no merge
-7 ancest+ (empty) remote no merge
-10 ancest^ ancest (empty) no merge
-9 ancest+ head (empty) no merge
-16 anc1/anc2 anc1 anc2 no merge
-13 ancest+ head ancest head
-14 ancest+ ancest remote remote
-11 ancest+ head remote no merge
+ case ancest head remote result
+ ----------------------------------------
+ 1 (empty)+ (empty) (empty) (empty)
+ 2ALT (empty)+ *empty* remote remote
+ 2 (empty)^ (empty) remote no merge
+ 3ALT (empty)+ head *empty* head
+ 3 (empty)^ head (empty) no merge
+ 4 (empty)^ head remote no merge
+ 5ALT * head head head
+ 6 ancest+ (empty) (empty) no merge
+ 8 ancest^ (empty) ancest no merge
+ 7 ancest+ (empty) remote no merge
+ 10 ancest^ ancest (empty) no merge
+ 9 ancest+ head (empty) no merge
+ 16 anc1/anc2 anc1 anc2 no merge
+ 13 ancest+ head ancest head
+ 14 ancest+ ancest remote remote
+ 11 ancest+ head remote no merge
Only #2ALT and #3ALT use *empty*, because these are the only cases
where there can be conflicts that didn't exist before. Note that we
unusually rich command set that provides both high-level operations
and full access to internals.
-Git is an Open Source project covered by the GNU General Public License.
-It was originally written by Linus Torvalds with help of a group of
-hackers around the net. It is currently maintained by Junio C Hamano.
+Git is an Open Source project covered by the GNU General Public
+License version 2 (some parts of it are under different licenses,
+compatible with the GPLv2). It was originally written by Linus
+Torvalds with help of a group of hackers around the net.
Please read the file INSTALL for installation instructions.
-#!/usr/bin/perl -w
-my %mailmap = ();
-open I, "<", ".mailmap";
-while (<I>) {
- chomp;
- next if /^#/;
- if (my ($author, $mail) = /^(.*?)\s+<(.+)>$/) {
- $mailmap{$mail} = $author;
- }
+#!/usr/bin/perl
+
+use warnings 'all';
+use strict;
+use Getopt::Long;
+
+my $match_emails;
+my $match_names;
+my $order_by = 'count';
+Getopt::Long::Configure(qw(bundling));
+GetOptions(
+ 'emails|e!' => \$match_emails,
+ 'names|n!' => \$match_names,
+ 'count|c' => sub { $order_by = 'count' },
+ 'time|t' => sub { $order_by = 'stamp' },
+) or exit 1;
+$match_emails = 1 unless $match_names;
+
+my $email = {};
+my $name = {};
+
+open(my $fh, '-|', "git log --format='%at <%aE> %aN'");
+while(<$fh>) {
+ my ($t, $e, $n) = /(\S+) <(\S+)> (.*)/;
+ mark($email, $e, $n, $t);
+ mark($name, $n, $e, $t);
}
-close I;
-
-my %mail2author = ();
-open I, "git log --pretty='format:%ae %an' |";
-while (<I>) {
- chomp;
- my ($mail, $author) = split(/\t/, $_);
- next if exists $mailmap{$mail};
- $mail2author{$mail} ||= {};
- $mail2author{$mail}{$author} ||= 0;
- $mail2author{$mail}{$author}++;
+close($fh);
+
+if ($match_emails) {
+ foreach my $e (dups($email)) {
+ foreach my $n (vals($email->{$e})) {
+ show($n, $e, $email->{$e}->{$n});
+ }
+ print "\n";
+ }
}
-close I;
-
-while (my ($mail, $authorcount) = each %mail2author) {
- # %$authorcount is ($author => $count);
- # sort and show the names from the most frequent ones.
- my @names = (map { $_->[0] }
- sort { $b->[1] <=> $a->[1] }
- map { [$_, $authorcount->{$_}] }
- keys %$authorcount);
- if (1 < @names) {
- for (@names) {
- print "$_ <$mail>\n";
+if ($match_names) {
+ foreach my $n (dups($name)) {
+ foreach my $e (vals($name->{$n})) {
+ show($n, $e, $name->{$n}->{$e});
}
+ print "\n";
}
}
+exit 0;
+sub mark {
+ my ($h, $k, $v, $t) = @_;
+ my $e = $h->{$k}->{$v} ||= { count => 0, stamp => 0 };
+ $e->{count}++;
+ $e->{stamp} = $t unless $t < $e->{stamp};
+}
+
+sub dups {
+ my $h = shift;
+ return grep { keys($h->{$_}) > 1 } keys($h);
+}
+
+sub vals {
+ my $h = shift;
+ return sort {
+ $h->{$b}->{$order_by} <=> $h->{$a}->{$order_by}
+ } keys($h);
+}
+
+sub show {
+ my ($n, $e, $h) = @_;
+ print "$n <$e> ($h->{$order_by})\n";
+}
return;
}
-static unsigned int contains(struct diff_filespec *one, struct diff_options *o,
+static unsigned int contains(mmfile_t *mf, struct diff_options *o,
regex_t *regexp, kwset_t kws)
{
unsigned int cnt;
unsigned long sz;
const char *data;
- if (!o->pickaxe[0])
- return 0;
- if (diff_populate_filespec(one, 0))
- return 0;
- sz = one->size;
- data = one->data;
+ sz = mf->size;
+ data = mf->ptr;
cnt = 0;
if (regexp) {
cnt++;
}
}
- diff_free_filespec_data(one);
return cnt;
}
static int has_changes(struct diff_filepair *p, struct diff_options *o,
regex_t *regexp, kwset_t kws)
{
- if (!DIFF_FILE_VALID(p->one)) {
- if (!DIFF_FILE_VALID(p->two))
- return 0; /* ignore unmerged */
+ struct userdiff_driver *textconv_one = get_textconv(p->one);
+ struct userdiff_driver *textconv_two = get_textconv(p->two);
+ mmfile_t mf1, mf2;
+ int ret;
+
+ if (!o->pickaxe[0])
+ return 0;
+
+ /*
+ * If we have an unmodified pair, we know that the count will be the
+ * same and don't even have to load the blobs. Unless textconv is in
+ * play, _and_ we are using two different textconv filters (e.g.,
+ * because a pair is an exact rename with different textconv attributes
+ * for each side, which might generate different content).
+ */
+ if (textconv_one == textconv_two && diff_unmodified_pair(p))
+ return 0;
+
+ fill_one(p->one, &mf1, &textconv_one);
+ fill_one(p->two, &mf2, &textconv_two);
+
+ if (!mf1.ptr) {
+ if (!mf2.ptr)
+ ret = 0; /* ignore unmerged */
/* created */
- return contains(p->two, o, regexp, kws) != 0;
- }
- if (!DIFF_FILE_VALID(p->two))
- return contains(p->one, o, regexp, kws) != 0;
- if (!diff_unmodified_pair(p)) {
- return contains(p->one, o, regexp, kws) !=
- contains(p->two, o, regexp, kws);
+ ret = contains(&mf2, o, regexp, kws) != 0;
}
- return 0;
+ else if (!mf2.ptr) /* removed */
+ ret = contains(&mf1, o, regexp, kws) != 0;
+ else
+ ret = contains(&mf1, o, regexp, kws) !=
+ contains(&mf2, o, regexp, kws);
+
+ if (textconv_one)
+ free(mf1.ptr);
+ if (textconv_two)
+ free(mf2.ptr);
+ diff_free_filespec_data(p->one);
+ diff_free_filespec_data(p->two);
+
+ return ret;
}
static void diffcore_pickaxe_count(struct diff_options *o)
test_cmp expect actual
'
+test_expect_success 'pickaxe (-S) operates on textconv data (add)' '
+ echo one >expect &&
+ git log --root --format=%s -S0 >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'pickaxe (-S) operates on textconv data (modification)' '
+ echo two >expect &&
+ git log --root --format=%s -S1 >actual &&
+ test_cmp expect actual
+'
+
cat >expect.stat <<'EOF'
file | Bin 2 -> 4 bytes
1 file changed, 0 insertions(+), 0 deletions(-)
'
# usage with rfc1991 signatures
-echo "rfc1991" > gpghome/gpg.conf
get_tag_header rfc1991-signed-tag $commit commit $time >expect
echo "RFC1991 signed tag" >>expect
echo '-----BEGIN PGP MESSAGE-----' >>expect
test_expect_success GPG \
'creating a signed tag with rfc1991' '
+ echo "rfc1991" >gpghome/gpg.conf &&
git tag -s -m "RFC1991 signed tag" rfc1991-signed-tag $commit &&
get_tag_msg rfc1991-signed-tag >actual &&
test_cmp expect actual
test_expect_success GPG \
'reediting a signed tag body omits signature' '
+ echo "rfc1991" >gpghome/gpg.conf &&
echo "RFC1991 signed tag" >expect &&
GIT_EDITOR=./fakeeditor git tag -f -s rfc1991-signed-tag $commit &&
test_cmp expect actual
test_expect_success GPG \
'verifying rfc1991 signature' '
+ echo "rfc1991" >gpghome/gpg.conf &&
git tag -v rfc1991-signed-tag
'
test_expect_success GPG \
'list tag with rfc1991 signature' '
+ echo "rfc1991" >gpghome/gpg.conf &&
echo "rfc1991-signed-tag RFC1991 signed tag" >expect &&
git tag -l -n1 rfc1991-signed-tag >actual &&
test_cmp expect actual &&