Merge branch 'maint' into tj/imap-send-remove-unused

* maint: (18123 commits)
  documentation fix: git difftool uses diff tools, not merge tools.
  Git 1.7.7.4
  Makefile: add missing header file dependencies
  notes merge: eliminate OUTPUT macro
  mailmap: xcalloc mailmap_info
  name-rev --all: do not even attempt to describe non-commit object
  Git 1.7.7.3
  docs: Update install-doc-quick
  docs: don't mention --quiet or --exit-code in git-log(1)
  Git 1.7.7.2
  t7511: avoid use of reserved filename on Windows.
  clone: Quote user supplied path in a single quote pair
  read-cache.c: fix index memory allocation
  make the sample pre-commit hook script reject names with newlines, too
  Reindent closing bracket using tab instead of spaces
  Git 1.7.7.1
  RelNotes/1.7.7.1: setgid bit patch is about fixing "git init" via Makefile setting
  gitweb: fix regression when filtering out forks
  Almost ready for 1.7.7.1
  pack-objects: don't traverse objects unnecessarily
  ...

Conflicts:
	imap-send.c

1 files changed, 49 insertions, 0 deletions

diff --git a/Documentation/technical/shallow.txt b/Documentation/technical/shallow.txt
new file mode 100644
index 0000000000..559263af48
--- /dev/null
+++ b/Documentation/technical/shallow.txt
@@ -0,0 +1,49 @@
+Def.: 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
+of $GIT_DIR/info/grafts (with the difference that shallow
+cannot contain parent information).
+
+This information is stored in a new file instead of grafts, or
+even the config, since the user should not touch that file
+at all (even throughout development of the shallow clone, it
+was never manually edited!).
+
+Each line contains exactly one SHA1. When read, a commit_graft
+will be constructed, which has nr_parent < 0 to make it easier
+to discern from user provided grafts.
+
+Since fsck-objects relies on the library to read the objects,
+it honours shallow commits automatically.
+
+There are some unfinished ends of the whole shallow business:
+
+- maybe we have to force non-thin packs when fetching into a
+  shallow repo (ATM they are forced non-thin).
+
+- A special handling of a shallow upstream is needed. At some
+  stage, upload-pack has to check if it sends a shallow commit,
+  and it should send that information early (or fail, if the
+  client does not support shallow repositories). There is no
+  support at all for this in this patch series.
+
+- Instead of locking $GIT_DIR/shallow at the start, just
+  the timestamp of it is noted, and when it comes to writing it,
+  a check is performed if the mtime is still the same, dying if
+  it is not.
+
+- It is unclear how "push into/from a shallow repo" should behave.
+
+- If you deepen a history, you'd want to get the tags of the
+  newly stored (but older!) commits. This does not work right now.
+
+To make a shallow clone, you can call "git-clone --depth 20 repo".
+The result contains only commit chains with a length of at most 20.
+It also writes an appropriate $GIT_DIR/shallow.
+
+You can deepen a shallow repository with "git-fetch --depth 20
+repo branch", which will fetch branch from repo, but stop at depth
+20, updating $GIT_DIR/shallow.